Smart Manufacturing Scheduling Under Data Latency: A Rolling-Horizon Two-Stage MILP Framework for OEM–Tier-1 Coordination

Abstract

Real-time coordination across OEM–Tier-1 manufacturing networks remains challenging due to delayed shop-floor data, stochastic machine availability, and the need for schedule stability. This paper presents a protocol-agnostic, two-stage mixed-integer linear programming (MILP) framework for real-time family-level scheduling. The method integrates MTConnect-like data streams without requiring adherence to any single communication standard. In Stage 1, a baseline plan is generated using expected capacity; in Stage 2, a rolling-horizon recourse model adapts the plan to observed (possibly lagged) capacity while incorporating a stability penalty to control resequencing. A synthetic OEM–Tier-1 testbed with three machines (two Tier-1, one OEM) is used to benchmark performance under real-time (L = 0) and delayed (L = 5) data scenarios. Across these scenarios, the real-time rolling scheduler improves strict on-time fulfillment by approximately 70% and eliminates terminal backlog relative to static planning, while MILP solve times remain under 0.1 s per cycle. Sensitivity experiments that vary disruption intensity, replanning interval (Δ), and stability weight (λ) show consistent qualitative trends and illustrate how the framework can be tuned to balance service performance against schedule stability without sacrificing computational tractability.

1. Introduction

The emergence of Industry 4.0 and the transition towards Industry 5.0 have placed real-time data and stakeholder management at the heart of modern manufacturing. As factories become increasingly connected and intelligent, the ability to integrate, analyze, and act on machine-level information is critical. Standardized data communication protocols such as MTConnect, OPC UA, and MQTT serve as the foundational layer enabling this transformation [1,2,3,4]. These protocols not only facilitate machine interoperability on the shop floor but also extend their influence across predictive maintenance, supplier collaboration, scheduling optimization, and supply chain resilience [5,6,7,8]. Recent digital-twin deployments [9,10,11,12] in additive manufacturing illustrate the same trend, where high-frequency machine telemetry is continuously fed into monitoring, diagnosis, and control loops rather than used only for offline analysis [13,14,15,16].

Smart manufacturing represents a continuous transformation of technologies, processes, skills, and strategies to satisfy future societal needs. In the evolving landscape of Industry 5.0, stakeholders including factory operators, systems integrators, equipment vendors, data analysts, and executive leadership are increasingly invested in achieving smarter, more adaptive manufacturing systems. Their shared goal is to drive operational efficiency, agility, and innovation through real-time visibility and seamless communication across the factory floor [6,7,8,17]. As factories shift toward human-centric, sustainable, and data-informed production, the ability to integrate machines of all types—legacy and modern—into unified digital ecosystems becomes critical. This is where standardized communication protocols play a foundational role.

Industry 5.0 initiatives depend on the seamless real-time data flow from machines to higher-level systems. Modern factories contain a diverse patchwork of equipment, from legacy PLC-controlled machines to advanced CNC tools, each often speaking different languages [5,6]. Various technologies now provide powerful tools to create leaner, more profitable, and data-driven manufacturing processes [7]. This digital transformation is enabled by standard communication protocols that provide a common language for equipment and software. In recent years, MTConnect, OPC Unified Architecture (OPC UA), and MQTT have emerged as prominent standards for connecting shop-floor devices to higher-level IT platforms. Each plays a distinct role in facilitating data exchange and interoperability. MTConnect (released in 2008) was one of the first widely adopted open standards for machine-tool data exchange. Building on this trend, prior work has argued that combining open-source machine tools with MTConnect can significantly lower integration costs and enable more accessible, innovation-friendly manufacturing ecosystems [18].

Despite these advances, real-time coordination between OEMs and upstream suppliers remains an open challenge. In this study, we focus on an OEM–Tier-1 interface as a representative, time-critical dyad in discrete manufacturing networks. Traditional scheduling frameworks often assume perfect visibility or static capacity, which breaks down when machine availability, transport times, and data latency vary dynamically. Prior studies have explored simulation-based and heuristic scheduling, but few integrate streaming shop-floor data with optimization in a tractable, interpretable way [18,19,20]. Moreover, most MILP-based scheduling studies applied to OEM–Tier-1 settings focus on single-tier or deterministic-capacity formulations. For example, Ghaleb et al. [17] develop a real-time MILP for single-facility job-shop scheduling under machine breakdowns but do not model cross-tier material coupling. Tighazoui et al. [21] propose a predictive–reactive MILP for parallel machines with rescheduling, yet assume a single production stage with no upstream dependencies. Wu et al. [22] present a rolling-horizon MILP for multiproduct batch scheduling but treat capacity as deterministic within each window and do not incorporate information lag. More recently, Sidki et al. [23] and Rosi et al. [24] address rolling-horizon lot-sizing with MILP, but both operate at a single echelon and do not penalize resequencing explicitly. While two-stage stochastic programming is inherently designed for dynamic adaptation optimizing a baseline in Stage 1 and recourse in Stage 2 existing applications rarely combine (i) joint OEM–Tier-1 family scheduling, (ii) an explicit information-lag parameter L, and (iii) a tunable stability penalty λ within a single rolling MILP framework. We note that two-stage MILP is structurally suited to dynamic replanning; the gap lies not in the method’s capability but in the absence of formulations that jointly address cross-tier coupling, information delay, and schedule stability within a single executable framework.

To address these limitations, this study develops a two-stage mixed-integer linear programming (MILP) framework for real-time adaptive scheduling across OEM–Tier-1 product families. The approach is protocol-agnostic, drawing inspiration from MTConnect-like streaming architectures yet independent of any specific communication standard. In Stage 1, a planning model generates a baseline family-level schedule under expected capacity; in Stage 2, a recourse model dynamically adapts this plan to observed machine availability while penalizing excessive resequencing through a tunable stability weight (λ).

A synthetic testbed representing coupled OEM–Tier-1 production lines is constructed to evaluate performance under varying disruption levels, data delays, and replanning intervals. Experimental results demonstrate that real-time coordination improves strict on-time fulfillment by approximately 70% compared with static planning, while maintaining MILP solvability under 0.1 s per iteration. The framework thus provides a scalable and explainable foundation for integrating real-time data with optimization-driven scheduling, an essential step toward Industry 5.0-ready supply networks.

The novelty of this study is threefold. First, we formulate a two-stage MILP that jointly schedules OEM and Tier-1 product families while explicitly modeling information lag L, transport delays, and a tunable stability penalty λ features that, to the best of our knowledge, have not been combined in a single executable framework. Second, the rolling-horizon pipeline is protocol-agnostic, compatible with MTConnect, OPC UA, or MQTT streams, and enforces both hard freeze windows and soft resequencing penalties. Third, we provide controlled numerical evidence comparing real-time (L = 0) and lagged (L > 0) visibility on OEM–Tier-1 KPIs under identical disruption realizations, quantifying the stability–agility trade-off.

The remainder of this paper is organized as follows: Section 2 presents the background, problem statement, and research objectives. Section 3 reviews related work on scheduling under uncertainty, industrial data standards, OEM–supplier coordination, and product-family planning. Section 4 introduces the system model, and Section 5 details the two-stage MILP formulation and rolling-horizon algorithm. Section 6 describes the experimental design. Section 7 reports results and sensitivity analyses. Section 8 discusses implications and limitations, Section 9 concludes, and Section 10 outlines future research directions.

2. Background, Problem Statement, and Research Setup

2.1. Background

Real-time manufacturing scheduling concerns how production decisions are updated as new shop-floor information becomes available [17,19,21,22]. In Industry 4.0/5.0 settings, machine states, buffer levels, and completion events are increasingly streamed through protocols such as MTConnect, OPC UA, and MQTT [1,25,26]. For OEM–Tier-1 chains, this real-time visibility can, in principle, align upstream production with downstream assembly, but it also creates the challenge of deciding how often to replan and how to keep schedules stable while reacting to disruptions.

2.2. Problem Statement

Modern factories stream machine states through standards like MTConnect/OPC UA/MQTT, yet most production plans still assume deterministic capacity and static schedules. When actual uptime/downtime deviates or when status arrives with information lag L, OEM assembly idles while Tier-1 WIP/backlog grows, lowering strict on-time fulfillment and destabilizing execution. Existing research addresses parts of this challenge (stochastic scheduling, supplier coordination, or product-family batching), but rarely unifies them into a single, executable framework that (i) schedules product families across an OEM–Tier-1 network, (ii) ingests live availability to re-optimize on a rolling horizon, and (iii) controls resequencing via a stability term. Our aim is a protocol-agnostic, MTConnect-compatible scheduling approach formulated as a two-stage MILP with rolling re-optimization and a short freeze window that quantifies how real-time vs. lagged information affects strict on-time fulfillment (OTFR_strict), backlog, utilization, and OEM idle time, while explicitly exposing the agility–stability trade-off through a tunable resequencing weight λ.

This study addresses the following research questions:

RQ1: Does real-time capacity visibility (L = 0) improve strict on-time fulfillment compared with lagged information (L > 0) in a rolling MILP framework for OEM–Tier-1 scheduling?

RQ2: Can a tunable stability penalty λ reduce schedule deviation without materially degrading service performance?

RQ3: How does the proposed two-stage rolling MILP compare with static planning and rolling deterministic alternatives on OEM–Tier-1 coordination KPIs?

The corresponding hypotheses are: (H1) OTFR_strict decreases monotonically with increasing L; (H2) increasing λ reduces schedule deviation with diminishing impact on backlog; and (H3) the rolling two-stage MILP outperforms static planning on all service KPIs.

2.3. Research Gaps

Despite widespread shop-floor telemetry via MTConnect/OPC UA/MQTT, many scheduling models still assume deterministic capacity and static plans. When uptime/downtime deviates from the plan or when status information arrives with a non-negligible lag $L$, OEM lines can sit idle while Tier-1 backlog accumulates. Existing work addresses pieces of this problem, but three gaps remain that are directly relevant to OEM–Tier-1 coordination with real-time data:

• Integrated OEM–Tier-1 family-level scheduling. Most mathematical models either optimize a single facility in isolation or treat upstream deliveries as exogenous. There are comparatively few tractable formulations that jointly schedule product families at a Tier-1 supplier and an OEM, while accounting for machine-level capacity, inventory, and transport delays between tiers.
• Explicit modeling of information delay and schedule stability in rolling MILPs.
  Prior studies incorporate uncertainty through stochastic processing times, robustness, or predictive maintenance triggers, but the planning layer typically assumes that capacity information is instantaneously available. The combined effect of a finite information lag $L$ (difference between true and observed capacity) and a tunable stability weight $\lambda$ that penalizes resequencing is rarely captured in a mixed-integer model that can be re-solved in real time.
• Quantitative evidence on the value of real-time connectivity for OEM performance.
  Many industrial case studies report qualitative benefits of MTConnect-like connectivity, yet there is limited controlled experimentation that compares real-time ($L=0$) versus lagged ($L>0$) capacity information and different replanning policies on key OEM–Tier-1 KPIs such as strict on-time fulfillment, backlog, utilization, and OEM idle time.

This paper addresses these gaps with a two-stage MILP and rolling-horizon framework that ingests live or lagged capacity, penalizes resequencing through $\lambda$, and experimentally compares real-time versus lagged information on OEM–Tier-1 performance and timing alignment.

2.4. Objectives

This study pursues the following objectives:

• Model: Develop a family-based, two-stage MILP that jointly schedules OEM and Tier-1 product families, explicitly capturing transport delays, information lag $L$, and a stability weight $\lambda$.
• Data pipeline: Emulate protocol-agnostic live capacity streams (e.g., MTConnect/OPC UA/MQTT) and feed them into a rolling-horizon scheduler with freeze windows and resequencing penalties.
• Policy comparison: Evaluate real-time re-optimization ($L=0$) against lagged-information baselines ($L>0$) and static planning with respect to OTFR_strict, backlog, OEM idle time, and utilization.
• Trade-off quantification: Quantify how the stability parameter $\lambda$ and replanning interval $\Delta$ trace the trade-off between agility (tardiness/backlog reduction) and schedule stability (limited resequencing).

2.5. Contributions

To address the above research gaps, this paper makes three contributions:

• Two-stage OEM–Tier-1 MILP:

A two-stage MILP for OEM–Tier-1 product-family scheduling that ingests live machine-availability streams, explicitly supports information lag $L$, transport delays, and penalizes resequencing via a stability weight $\lambda$, while remaining solvable in (near) real time.

2.

Protocol-agnostic rolling-horizon pipeline:

A rolling-horizon, protocol-agnostic implementation (compatible with MTConnect/OPC UA/MQTT) that re-optimizes events or at fixed intervals and freezes near-term actions, providing executable stability through hard freeze windows and soft resequencing penalties.

3.

Controlled numerical evidence on real-time vs. lagged data:

Experimental evidence that real-time data ($L=0$) improves OTFR_\text{strict}, reduces backlog and OEM idle time, and yields more consistent outcomes than lagged baselines ($L>0$), with sensitivity analyses that vary $L$ and $\lambda$ and quantify the stability–agility trade-off.

Compared with prior scheduling studies, the proposed work is novel in three respects. First, it jointly optimizes OEM and Tier-1 product-family schedules in a two-stage MILP that explicitly incorporates information lag $L$, transport delays, and a tunable stability weight $\lambda$, while remaining solvable in real time. Second, the framework is protocol-agnostic but naturally compatible with MTConnect, OPC UA, or MQTT streams, allowing live machine availability to drive rolling re-optimization with both hard freeze windows and soft resequencing penalties. Third, we provide controlled numerical evidence, under identical disruption realizations, that real-time connectivity ($L=0$) yields higher strict on-time fulfillment and lower backlog/OEM idle time than lagged baselines ($L>0$), and we quantify how changing $\lambda$ traces out an explicit stability–agility trade-off. Together, these elements differentiate the study from existing static MILPs, heuristic dispatch rules, and qualitative IoT case reports in the literature.

3. Literature Review

3.1. Scheduling Under Uncertainty

Classical production scheduling with uncertain processing/availability has long leveraged stochastic models, robust optimization, and rolling-horizon control [17,27,28]. Typical formulations hedge against variability using expected capacities, safety buffers, or scenario sets, but execution often remains open-loop between replans. Dynamic and reactive scheduling mitigates this by periodically re-optimizing [19,20], employing dispatching rules (e.g., EDD, ATC), and using myopic look-ahead to respond to disturbances. Event-triggered schemes (e.g., on breakdown/repair) reduce latency between disruption and decision, yet many implementations assume a single site and simplified capacity surrogates, or treat machine availability as exogenous noise rather than an explicit, time-stamped signal [17,19,21]. Moreover, stability, i.e., limiting resequencing churn when plans update, tends to be handled informally (e.g., freeze windows) rather than through explicit penalties in the objective [19,21]. In sum, the literature establishes the value of rolling re-optimization under uncertainty but leaves open a unified, stability-aware formulation that consumes live availability to jointly optimize service [17,19,27,28], flow, and plan robustness in two-echelon settings. A structured summary of representative scheduling-under-uncertainty studies is provided in Table 1, highlighting their assumptions and limitations. Overall, this literature demonstrates the value of rolling re-optimization under uncertainty, but it still lacks a unified, stability-aware formulation that consumes live availability data to jointly optimize service, flow, and robustness in coupled OEM–Tier-1 settings [19].

Table 1. Comparison of representative MILP-based scheduling studies with the proposed framework.

Study	Method	Multi-Tier?	Rolling Horizon?	Info Lag L?	Stability Penalty?
Ghaleb et al. [17]	MILP, single facility	No	Yes	No	No
Tighazoui et al. [21]	Predictive–reactive MILP	No	Yes	No	Freeze only
Wu et al. [22]	Rolling GDP/MILP, batch	No	Yes	No	No
Rosi et al. [24]	Rolling MILP, lot-sizing	No	Yes	No	No
Sidki et al. [23]	Rolling MILP, prod.-distrib.	Partial	Yes	No	No
Duan & Wang [27]	Robust job-shop MILP	No	No	No	Robustness measure
This paper	Two-stage rolling MILP	Yes (OEM–Tier-1)	Yes	Yes	Yes (λ)

It is worth positioning the proposed two-stage MILP relative to two alternative paradigms. Multistage stochastic programming would model capacity uncertainty across multiple future periods with scenario trees, yielding richer recourse but at exponential computational cost, making real-time re-solving impractical for the rolling-horizon cycles (Δ = 5 slots) targeted here. Robust optimization would hedge against worst-case capacity realizations, producing conservative schedules that sacrifice throughput for guaranteed feasibility. Our two-stage formulation occupies a pragmatic middle ground: Stage 1 provides a baseline under expected capacity (analogous to a deterministic equivalent), and Stage 2 adapts to observed (possibly lagged) capacity with a stability penalty that limits resequencing. This design trades theoretical optimality guarantees for computational tractability and interpretability properties that are essential for near-real-time OEM–Tier-1 coordination.

3.2. Role of Industrial Data Standards in Scheduling

Industrial data standards serve as the communication layer that makes machine states available to planning systems; they are not scheduling methods themselves but rather the interfaces through which scheduling algorithms receive input data. MTConnect provides a vendor-neutral, read-only, semantically rich model of devices, events, and time-aligned samples, well-suited for manufacturing telemetry and traceability [1,26]. OPC UA offers a broader service stack with security and methods, enabling command-and-control and enterprise integration. MQTT supplies lightweight publish–subscribe transport at scale, commonly used as an IIoT backbone.

While these standards have largely solved the interoperability problem on the shop floor, their integration into closed-loop scheduling remains limited. Two gaps are relevant to the present study: (i) shop-floor data from these protocols are typically logged for dashboards and offline analytics rather than fed back into optimization solvers with timing guarantees, and (ii) studies rarely quantify how the effective information lag L introduced by polling intervals, buffering, and gateway hops degrades schedule quality when the data eventually reach the planner. In our framework, any of these protocols (or a combination) can populate the observed capacity stream cap^obs_{m,t}; the MILP scheduler is protocol-agnostic and consumes the data regardless of its source.

Table 2 summarizes representative milestones in MTConnect deployment and reported impacts from 2008 to 2025 [25,26].

Table 2. MTConnect adoption and impact timeline (2008–2025): years, deployment contexts, data scopes (events/samples/condition), reported outcomes (OEE, downtime, scrap), and noted limitations relative to closed-loop scheduling.

Year	Use Case	Description
2008 [26]	MTConnect Released	Early MTConnect efforts and foundational concepts for standardized machine-tool data exchange.
2012–2015 [25,26]	Early Adoption in Aerospace	Early pilots/testbed-style deployments use MTConnect for condition monitoring and predictive maintenance in aerospace machining lines.
2016–2018 [25,26]	Pilot Projects in Automotive & Medical	Automotive OEMs and medical device firms begin piloting MTConnect for spindle monitoring, cycle time analysis, and part traceability.
2019 [1,25]	Rise of Hybrid Protocols	Integration with OPC UA and MQTT begins, enabling better edge-to-cloud architecture; MTConnect becomes part of multi-protocol digital threads
2020–2022 [2,25,29]	Pandemic-Era Shift: Remote Monitoring	Remote work accelerates MTConnect-based dashboards for visibility into contract manufacturing, especially in medical and defense sectors.
2023 [2]	EV & Battery Assembly Adoption	MTConnect is implemented in EV battery production lines to track live assembly torque, heat, and quality metrics across global suppliers.
2024 [2,29]	Aerospace Structural Assembly	Tier-1 aerospace suppliers use MTConnect to stream drill depth, alignment, and inspection data live to OEMs for certification and benchmarking.
2025 [5,8,29]	Human–Machine Collaboration in Industry 5.0	MTConnect supports real-time feedback loops in smart assembly cells, where operators, robots, and AI systems collaborate using a unified data layer.

3.3. OEM–Supplier or Multi-Tier Scheduling

Information sharing can dampen bullwhip effects and synchronize upstream production with downstream assembly [1,2]. Prior work on VMI/CPFR and digital collaboration shows service and inventory benefits when status visibility improves; however, most models exchange demand/stock signals rather than machine availability. In discrete manufacturing, the timing mismatch between Tier-1 completions and OEM starts creates idle gaps and WIP accumulation when disruptions occur and status arrives late [30]. Multi-echelon scheduling studies demonstrate benefits from joint planning but frequently rely on deterministic lead times or static freeze plans. Few contributions visualize or quantify timeline alignment (Tier-1 completion → transit → OEM start) with and without real-time signals. Consequently, the precise impact of live availability on OEM idle time, strict on-time fulfillment, and backlog across tiers remains under-specified, motivating coordination policies that re-optimize when signals change, not merely when a weekly plan is revisited.

3.4. Product-Family Planning and Setup-Aware Batching

Family-based planning groups similar SKUs to reduce setups and exploit shared routings, with binary family-machine-time decisions $z_{f,m,t}$ controlling eligibility and changeover variables capturing sequence-dependent setups [2,3]. Classic results show that batching can lift throughput and stabilize flow, but only when capacity and sequence decisions co-evolve. Under disruptions, families can buffer variability, yet stale capacity assumptions propagate misallocated time and excess backlog. Many formulations either (i) neglect time-stamped availability and recompute on fixed cycles, or (ii) control stability via heuristic freeze windows without an explicit stability penalty. What is still limited are two-echelon, family-aware models that (a) ingest live availability (or explicit lag $L$), (b) incorporate setup times and optional changeover penalties, and (c) quantify the agility–stability trade-off via a tunable weight $\lambda$ while reporting operational KPIs (OTFR_strict, backlog, utilization).

3.5. Industry 4.0/5.0 Context and Data Pipelines

Industry 4.0/5.0 emphasizes interoperable, explainable, and resilient operations. Architectures commonly follow device → edge/agent → broker → application pipelines, with digital twins for state estimation and what-if planning [31,32]. In practice, planners face sampling, transport, and compute delays, creating an effective information lag $L$ that can erode decision quality if not modeled [17,18]. While frameworks abound for streaming analytics, fewer studies instrument the planning loop end-to-end measuring how lag $L$ and stability controls affect service and flow. A pragmatic design is a protocol-agnostic ingestion layer (MTConnect/OPC UA/MQTT) feeding a rolling optimizer that re-solves on intervals/events and freezes near-term actions to balance agility and execution stability [1,22,24,25]. Our work operationalizes this pattern and quantifies its impact in a two-tier, family-based setting.

3.6. Bridge to Methodology

Building on the above, we operationalize a protocol-agnostic, rolling scheduling pipeline and a two-stage MILP that (i) ingests live availability (or explicit lag $L$), (ii) penalizes resequencing via a stability weight $\lambda$, and (iii) supports family batching and optional setups. The next section details sets, parameters, decisions, and the rolling execution policy (re-solve interval/events with a short freeze window), followed by experiments quantifying performance and sensitivity to $L$ and $\lambda$.

4. Problem Description and System Model

4.1. System Overview

We consider a two-echelon discrete-time manufacturing network consisting of a Tier-1 supplier and an OEM.

Let $t=1,\dots ,H$ denote discrete time slots.

Each machine $m\in M_S\cup M_O$ has a true available capacity $ca{p}_{m,t}^{real}$ (e.g., minutes per slot) and an observed capacity stream

$$\mathrm{c}\mathrm{a}{\mathrm{p}}_{\mathrm{m},\mathrm{t}}^{\mathrm{o}\mathrm{b}\mathrm{s}}=\{\begin{array}{cc}\mathrm{c}\mathrm{a}{\mathrm{p}}_{\mathrm{m},\mathrm{t}}^{\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{l}},& \mathrm{if} \mathrm{L}=0,\\ \mathrm{c}\mathrm{a}{\mathrm{p}}_{\mathrm{m},\mathrm{t}-\mathrm{L}}^{\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{l}},& \mathrm{if} \mathrm{L}>0,\end{array}$$

where $L$ is the information-lag parameter.

A rolling-horizon controller re-optimizes every $\Delta$ slots and freezes the next $\delta$ slots for execution stability.

The architecture is protocol-agnostic: MTConnect, OPC UA, or MQTT streams can populate $ca{p}_{m,t}^{obs}$.

4.2. Product-Family Structure

Let $F=F_S\cup F_O$ be the set of all product families, partitioned into Tier-1 families $F_S$ and OEM families $F_O$.

Each family $f\in F$ is characterized by

• Average processing time $p_{f,m}$ on machine $m$;
• Total quantity $Q_f$;
• Setup time $s_{f,g,m}$ when switching from $f$ to $g$ on machine $m$;
• Eligible-machine set $M_f\subseteq M$.

Decision variables:

$$x_{f,m,t}=\mathrm{units} \mathrm{of} \mathrm{family} f \mathrm{processed} \mathrm{on} \mathrm{machine} m \mathrm{at} \mathrm{slot} t.$$

Machine capacity constraint (generic form):

$$\sum _{f\in F_m}{p}_{f,m}\hspace{0.17em}{x}_{f,m,t}\le ca{p}_{m,t}^{obs},\forall m,t.$$

Family-level aggregation captures batching and reduces model size while retaining setup-change logic when needed.

In the synthetic testbed, we use three Tier-1 families $S_1,S_2,S_3$ and two OEM families $O_1,O_2$. Their demands, processing-time ranges, eligible machines, and setup times are summarized in Table 5.

4.3. OEM–Tier-1 Coupling

Let $P\subseteq F_S\times F_O$ denote precedence pairs where Tier-1 family $f_s$ supplies OEM family $f_o$.

Let $t{r}_{f_s,f_o}$ be the deterministic transport delay (in slots).

Material-balance coupling is enforced as

$${\mathrm{Start}}_{f_o}^{OEM}\hspace{0.25em}\ge \hspace{0.25em}{\mathrm{Completion}}_{f_s}^{Tier1}+t{r}_{f_s,f_o},\left(f_s,f_o\right)\in P.$$

Inventory evolution for each pair $(f_s,f_o)$:

$$I_{f_s,f_o,t}=I_{f_s,f_o,t-1}+\sum _{m\in M_S}{x}_{f_s,m,t-t{r}_{f_s,f_o}}-{ y}_{f_o,t},$$

where $y_{f_o,t}$ is the OEM output of $f_o$ in slot $t$.

Availability of upstream items limits downstream production:

$$y_{f_o,t}\le I_{f_s,f_o,t},\forall (f_s,f_o)\in P,\hspace{0.17em}t.$$

Illustrative example:

• Let $F_S=\{s_1,s_2\}$, $F_O=\left\{o_1\right\}$, with $t{r}_{s_1,o_1}=2$ and $t{r}_{s_2,o_1}=1$.
• If Tier-1 completes five units of $s_1$ at $t=4$ and five units of $s_2$ at $t=5$, then the earliest OEM start is $\mathrm{m}\mathrm{a}\mathrm{x}(4+2,\hspace{0.25em}5+1)=6$.
• With lag $L=5$, the planner at $t=6$ only “sees” data up to $t=1$, potentially mistiming OEM starts, precisely the mis-coordination quantified in our rolling MILP.

4.4. Assumptions

• Finite horizon: Plan over $H$ slots; re-solve every $\Delta$ slots; freeze $\delta$ slots.
• Processing parameters: Within each family, $p_{f,m}$ is deterministic and constant over $H$.
• Availability process: Machine status drives $ca{p}_{m,t}^{real}\hspace{0.17em}\in \hspace{0.17em}\left[\mathrm{0,1}\right]$; planner uses $ca{p}_{m,t}^{obs }$ lagged by $L$.
• No preemption: All work assigned in slot $t$ completes within that slot.
• Priority: Jobs within a family are homogeneous; external priorities are handled via $w_f^{tard}$ or due windows.
• Material balance: Tier-1 output feeds OEM input after $t{r}_{f_s,f_o}$; OEM output contributes to service/backlog metrics.
• Stability control: Soft resequencing penalty plus hard freeze window $\delta$ limits plan churn.

  $$\lambda \sum _{f,m,t}\left|x_{f,m,t}-x_{f,m,t}^{\mathrm{prev}}\right|$$
• Unit consistency: If capacity is [min/slot] and $p_{f,m}$ [min/unit], then $x_{f,m,t}$ [units], ensuring

  $${\sum }_f{p}_{f,m}{x}_{f,m,t}\le ca{p}_{m,t}^{obs}.$$

5. Methodology

Before presenting the detailed formulation, we provide a high-level summary. The model is a linear program with continuous production variables {x_f,m,t}, inventory and backlog tracking variables, and stability slack variables. The objective minimizes weighted backlog plus a λ-scaled resequencing penalty. Key constraints enforce: (1) machine capacity limits using observed (possibly lagged) capacity, (2) inventory–backlog balance across time for each family, (3) OEM–Tier-1 precedence with transport delays, and (4) stability tracking via linearized absolute differences. All constraints are linear; the model contains no binary variables unless optional setup/sequencing is enabled. The formulation is solved repeatedly within a rolling-horizon loop that freezes near-term decisions and carries the state forward.

5.1. Decision Variables and Parameters

Sets

• $F_S$: Tier-1 (supplier) families;
• $F_O$: OEM (assembly) families;
• $F=F_S\cup F_O$: all families;
• $M_S$: Tier-1 machines;
• $M_O$: OEM machines;
• $M=M_S\cup M_O$: all machines;
• $T=\{1,\dots ,H\}$: time slots in the current planning/recourse window;
• $P\subseteq F_S\times F_O$: precedence pairs $(f_s,f_o)$ where $f_s$ supplies $f_o$.

Parameters

• $p_{f,m}\ge 0$: capacity (time) consumed to process 1 unit of family $f$ on machine $m$;
• ${\widehat{cap}}_{m,t}\ge 0$: expected/forecast capacity for machine $m$ at time $t$ (used in Stage 1);
• $ca{p}_{m,t}^{real}\ge 0$: true capacity (from emulator);
• $ca{p}_{m,t}^{obs}\ge 0$: observed/planner capacity (used in Stage 2), defined by

  $$ca{p}_{m,t}^{obs}=\{\begin{array}{cc}ca{p}_{m,t}^{real},& L=0,\\ ca{p}_{m,t-L}^{real},& L>0,\end{array}$$

  (1)
• $d_{f_o,t}\ge 0$: external demand for OEM family $f_o\in F_O$ at time $t$;
• $t{r}_{f_s,f_o}\ge 0$: transport delay (in slots) from Tier-1 family $f_s$ to OEM family $f_o$;
• $w_{f_o}^{tard}\ge 0$: weight/penalty for backlog of OEM family $f_o$;
• $\lambda \ge 0$: stability weight;
• $x_{f,m,t}^{prev}\ge 0$: plan committed in previous solve, for stability tracking;
• ${\mathrm{bigU}}_{f,m}\ge 0$: large upper bound for coupling/eligibility;
• Initial inventories: ${\mathrm{inv}}_{f,0}\ge 0$ for all $f\in F$;
• Initial backlogs: ${\mathrm{back}}_{f_o,0}\ge 0$ for all $f_o\in F_O$.

Decision variables (Stage 2, main model)

• $x_{f,m,t}\ge 0$: quantity of family $f$ processed on machine $m$ at time $t$;
• $r_{f_s,f_o,t}\ge 0$: quantity of Tier-1 family $f_s$ allocated at time $t$ to OEM family $f_o$;
• ${\mathrm{inv}}_{f,t}\ge 0$: inventory/WIP of family $f$ at end of time $t$;
• ${\mathrm{back}}_{f_o,t}\ge 0$: backlog for OEM family $f_o$ at end of time $t$;
• $z_{f,m,t}\ge 0$: stability (absolute difference) slack.

Optional (only if we enable setups/changeovers)

• $z_{f,m,t}^{bin}\in \{\mathrm{0,1}\}$: machine $m$ assigned to family $f$ at time $t$;
• $u_{f\to g,m,t}\in \left\{\mathrm{0,1}\right\}$: changeover on $m$ at time $t$ from family $f$ to family $g$.

5.2. Stage-1 MILP (Planning Model)

Purpose: build a first feasible schedule for the window using forecast/expected capacity, before we see the actual (possibly lagged) capacity.

Stage-1 decision variables

• ${\bar{x}}_{f,m,t}\ge 0$: planned production for family $f$ on machine $m$ at time $t$ (expected plan);
• ${\stackrel{\mathrm{‾}}{\mathrm{inv}}}_{f,t}\ge 0$, ${\stackrel{\mathrm{‾}}{\mathrm{back}}}_{f_o,t}\ge 0$: expected inventories/backlogs.

Stage-1 objective (simple service):

$$\min \sum _{f_o\in F_O}\sum _{t\in T}{w}_{f_o}^{tard}\hspace{0.17em}bac{k}_{f_o,t}$$

(2)

Stage-1 machine capacity:

$$\sum _{f\in F}{p}_{f,m}\hspace{0.17em}{x}_{f,m,t}\le \widehat{ca{p}_{m,t}},\hspace{1em}\forall m\in M,\hspace{0.25em}t\in T$$

(3)

Stage-1 material/demand balance follows the same structure as Stage 2 (below) but uses the “bar” variables and $\widehat{cap}$. The output of Stage 1 is not what we report in Results; it is what we feed as $x_{f,m,t}^{prev}$ into Stage 2 to let the stability term work.

5.3. Stage-2 MILP (Recourse Model)

Purpose: Adapt the Stage-1 plan to the observed capacity $ca{p}_{m,t}^{obs}$ and the actual (possibly delayed) machine availability, and penalize changes from the previous plan.

Stage-2 objective (service + stability):

$$\min \sum _{f_o\in F_O}\sum _{t\in T}{w}_{f_o}^{tard}\hspace{0.17em}bac{k}_{f_o,t}+\mathrm{\lambda }\sum _{f\in F}\sum _{m\in M}\sum _{t\in T}{Z}_{f,m,t }$$

(4)

This is exactly the form we used in the Python 6.7.1 runs.

5.4. Objective Function

To show the optional throughput/priority term (not used in all runs, but compatible), the “general” objective can be presented:

$$\min {\alpha }_1\hspace{0.17em}\sum _{f_o\in F_O}\sum _{t\in T}{w}_{f_o}^{tard}bac{k}_{f_o,t}+{\mathrm{\alpha }}_2\sum _{f\in F}\sum _{m\in M}\sum _{t\in T}{Z}_{f,m,t}-{\mathrm{\alpha }}_3\sum _{f\in F}\sum _{m\in M}\sum _{t\in T}{x}_{f,m,t }$$

(5)

where

• ${\alpha }_1>0$: service priority;
• ${\alpha }_2=\lambda$: stability weight;
• ${\alpha }_3\ge 0$: (optional) reward for throughput.

In our experiments, we set the optional throughput/priority reward term to zero, so the objective reduces to the service + stability form.

5.5. Constraints

(1) Capacity (observed stream)

For every machine and slot, we must obey the capacity that the planner actually sees:

$$\sum _{f\in F}{p}_{f,m}\hspace{0.17em}{x}_{f,m,t}\le ca{p}_{m,t}^{obs},\hspace{1em}\forall m\in M,\hspace{0.25em}t\in T$$

(6)

This is the key difference from Stage 1 (which used $\widehat{cap}$).

(2) Family processing/inventory continuity

(2a) Tier-1 (supplier) families

For every Tier-1 family $f_s\in F_S$ and time $t\in T$:

$$in{v}_{f_s,t}=in{v}_{f_s,t-1}+\sum _{m\in M_S}{x}_{f_s,m,t}-\sum _{f_o:\left(f_s,f_o\right)\in P}{r}_{f_s,f_o,t}$$

(7)

Interpretation: stock at Tier-1 = yesterday’s stock + today’s production − what we send to OEM.

(2b) OEM (assembly) families, with transport delay

First define delayed arrivals:

$$arriv{e}_{f_o,t}=\sum _{f_s:\left(f_s,f_o\right)\in P}{r}_{f_s,f_o,t-t{r}_{f_s,f_o}}(\mathrm{terms} \mathrm{with} \mathrm{negative} \mathrm{index} \mathrm{are} 0)$$

(8)

Then define OEM inventory balance, for all $f_o\in F_O,\hspace{0.25em}t\in T$:

$$in{v}_{f_o,t}=in{v}_{f_o,t-1}+arriv{e}_{f_o,t}-\sum _{m\in M_O}{x}_{f_o,m,t}$$

(9)

This enforces that OEM cannot produce more of $f_o$ than what arrived plus what was already in its buffer.

(3) OEM–Tier-1 precedence (feasibility form)

Arrivals must be nonnegative and cannot exceed what Tier-1 had:

$$0\hspace{0.25em}\le \hspace{0.25em}{r}_{f_s,f_o,t}\hspace{0.25em}\le \hspace{0.25em}{\mathrm{inv}}_{f_s,t},\forall (f_s,f_o)\in P,\hspace{0.25em}t\in T$$

(10)

Together, the OEM–Tier-1 precedence constraints in Section 5.5 enforce the same logic as “Start ≥ Completion + tr” but expressed in a material-flow form (which is what we implement in the experiments).

(4) Service/backlog recursion

For each OEM family $f_o$ and time $t$:

$$bac{k}_{f_o,t}\ge bac{k}_{f_o,t-1}+d_{f_o,t}-{\sum }_{m\in M_O}{x}_{f_o,m,t} \ge 0$$

(11)

This is the same structure we used for OTFR/backlog in the plots.

(5) Stability tracking

To penalize changes from the previous plan, we linearize the absolute value:

$$z_{f,m,t}\hspace{0.25em}\ge \hspace{0.25em}{x}_{f,m,t}-x_{f,m,t}^{prev},\forall f,m,t$$

(12)

$$z_{f,m,t}\hspace{0.25em}\ge \hspace{0.25em}-x_{f,m,t}+x_{f,m,t}^{prev},\forall f,m,t$$

(13)

Then $\lambda \sum z_{f,m,t}$ appears in the objective (4).

(6) Optional setup/sequencing constraints

Only include if you want the “one family per machine per slot” behavior.

(6a) Machine-family assignment

$$\sum _{f\in F}{z}_{f,m,t}^{bin}\hspace{0.25em}\le \hspace{0.25em}1,\forall m,t$$

(14)

(6b) Couple flow to assignment

$$x_{f,m,t}\hspace{0.25em}\le \hspace{0.25em}{\mathrm{bigU}}_{f,m}\cdot z_{f,m,t}^{bin},\forall f,m,t$$

(15)

(6c) Capacity with setup loads

$$\sum _{f\in F}{p}_{f,m}\hspace{0.17em}{x}_{f,m,t}+\sum _{f\ne g}{s}_{f,g,m}\hspace{0.17em}{u}_{f\to g,m,t}\le ca{p}_{m,t}^{obs},\hspace{1em}\forall m,t$$

(16)

All constraints in the core model (Equations (6)–(13)) are necessary and non-redundant: capacity (Equation (6)) prevents over-allocation; balance (Equations (7)–(9)) tracks material flow; precedence (Equation (10)) enforces cross-tier coupling; backlog (Equation (11)) measures service; and stability (Equations (12) and (13)) enables the λ trade-off. The setup/sequencing constraints (Equations (14)–(16)) are presented as optional because not all OEM–Tier-1 settings require explicit changeover modeling, for example, when families share tooling or when changeover times are negligible relative to slot duration. In our experiments, setups are disabled to isolate the effect of information lag and stability control. The entire formulation is linear: the absolute-value term in the stability penalty is linearized via standard slack variables (Equations (12) and (13)), and all other constraints are affine in the decision variables. No hidden nonlinearities exist.

5.6. Real-Time Data Emulation

In the experiments, live machine data are emulated rather than collected from a physical line. For each machine, we first generate an alternating sequence of up and down periods. The length of each period is drawn from a stochastic distribution (Weibull or exponential), so that some breakdowns are short and others are longer. When the machine is up, it has its nominal capacity in that time slot; when it is down, the capacity is set to zero. This gives the “true” capacity profile over the full horizon.

To model delayed information, we create an “observed” capacity profile by shifting the true series by an information lag $L$ [20]. The case $L=0$ represents real-time visibility, while $L>0$ represents increasingly delayed feedback from the shop floor.

The rolling scheduler uses the observed capacity profile as input. A re-optimization is carried out at regular intervals $\Delta$ (e.g., every few time slots) and, in some experiments, also whenever a machine changes its state from up to down or down to up. At each re-optimization, the MILP is solved over a horizon of length $H$, and only the first $\delta$ time slots of the new plan are frozen and sent for execution. This setup mimics how a controller would use streaming machine data to update the schedule in real time [25,29].

5.7. Rolling-Horizon Algorithm

The rolling scheduler works in repeated cycles. At a high level, it always looks ahead over a finite horizon, decides what to do, executes only the near-term part of that plan, and then repeats with updated information [22,23,24].

The procedure is:

• Initialization: Set the global time index $k=1$. Read the initial inventories and backlogs for all families and initialize the previous schedule $x_{f,m,t}^{\mathrm{prev}}=0$.
• Build the planning window:

At time $k$, define the current horizon

$$T_k=\{k,k+1,\dots ,k+H-1\},$$

where $H$ is the rolling-horizon length.

3.

Read observed capacity: For every machine and time in $T_k$, take the observed (possibly lagged) capacity ${\mathrm{cap}}_{m,t}^{\mathrm{obs}}$ from the emulated data stream (Section 5.6).

4.

Solve the MILP: Solve the Stage-2 model over the current planning window using the objective in Section 5.4 and the feasibility constraints in Section 5.5 (optionally including the setup/assignment constraints if enabled). The solution provides the planned production, shipment, and inventory decisions for all families, machines, and time slots in the window.

5.

Freeze and dispatch: Only the first $\delta$ time slots of the schedule are committed to execution. These decisions are sent to the machines, while the remaining slots in $T_k$ are treated as provisional.

6.

Update state: After executing the committed (frozen) portion of the plan, update inventories and backlogs using the same material-balance and backlog recursion logic defined in Section 5.5. The executed schedule becomes the new reference plan for computing stability penalties in the next rolling iteration. $x_{f,m,t}^{\mathrm{prev}}=x_{f,m,t} \mathrm{for} t\in \{k,\dots ,k+\delta -1\}$.

7.

Advance time:

Move the global time index to the next decision point, $k\leftarrow k+\delta$.

8.

Termination:

If $k$ exceeds the global horizon $T_{\mathrm{global}}$, stop; otherwise, return to Step 2 and re-optimize with the latest observed data.

This is exactly the loop used to generate all rolling-horizon results (backlog vs. information lag, OTFR vs. lag, and the Gantt charts).

5.8. Validation Setup

To test the framework in a controlled setting, we use a synthetic OEM–Tier-1 testbed:

System configuration:

The instance includes three Tier-1 families ($S_1,S_2,S_3$), two OEM families ($O_1,O_2$), and 2–3 machines on the Tier-1 side plus 2 machines at the OEM. Transport times between Tier-1 and OEM are between 1 and 3 time slots. The demand for each OEM family is generated as a time series over the horizon.

Disruption levels:

Machine uptime and downtime patterns are tuned to create three disruption regimes:

• Low: long up-times and short interruptions (high effective capacity).
• Medium: balanced up/down periods.
• High: frequent or long breakdowns, creating tight capacity and more backlog pressure.
• Replications:
  For each disruption level and information-lag setting $L$, we run multiple stochastic replications with different random seeds (10 in the reported results) and average the outcomes. This yields means and standard deviations for all KPIs.
• Performance measures:

The main KPIs are:

• Strict on-time fulfillment ${\mathrm{OTFR}}_{\mathrm{strict}}$;
• Total backlog at the OEM;
• OEM idle time;
• Machine utilization;
• Schedule-change magnitude $\mathrm{\lambda }{\sum }_{f,m,t}\left|x_{f,m,t}-x_{f,m,t}^{\mathrm{prev}}\right|$;
• MILP solve time per re-optimization cycle.

These settings are chosen to be large enough to stress the model while keeping the instance interpretable and reproducible for future work.

5.9. Conceptual Link to MTConnect

This mapping mirrors practical MTConnect architectures reported in industry and academic case studies [1,25,26] where machines act as devices, an intermediate agent buffers and timestamps events, and scheduling or analytics engines consume the resulting streams. In MTConnect, Device refers to the physical asset that generates raw state data, Agent buffers and serves that data (optionally applying filtering or delay), and Application is the client that consumes the stream for decision-making. In our study, these layers are mirrored by the machine/state emulator that produces the real capacity series $ca{p}_{m,t}^{\mathrm{real}}$, the parser that applies an information lag $L$ to create the observed series $ca{p}_{m,t}^{\mathrm{obs}}$, and the rolling Stage-2 MILP scheduler that repeatedly solves using this delayed stream.

6. Experimental Design

All experiments in this study are conducted using a simulation-based testbed rather than data from a physical production line. The testbed emulates a coupled OEM–Tier-1 manufacturing network with five machines (three at Tier-1, two at OEM) and five product families (S₁–S₃, O₁–O₂). Machine availability is generated synthetically using alternating up/down periods drawn from a Weibull distribution (β = 1.8, η = 12), producing realistic disruption patterns at three severity levels. The information-lag parameter L is applied by shifting the true capacity series, so the planner observes delayed data. The MILP models are implemented in Python 6.7.1 using the Pyomo optimization framework with the HiGHS 1.7.0 solver on a standard Intel i7 processor. Each scenario is replicated 10 times with distinct random seeds to obtain statistically meaningful results (mean ± 95% confidence intervals). This controlled simulation design allows isolation of individual factors—information lag, stability weight, and disruption intensity—which would be difficult to achieve in a live industrial setting.

6.1. Factorial Structure

A full-factorial experiment was conducted to evaluate the performance of the rolling MILP scheduler under varying conditions of volatility, information lag, and stability penalization.

The mapping between MTConnect layers and the proposed emulation framework is summarized in Table 3. The factors and their corresponding levels are summarized in Table 4.

Table 3. Mapping between MTConnect layers and the proposed emulation framework.

MTConnect Layer	Analog in This Work
Device	Machine/state emulator that produces $ca{p}_{m,t}^{real}$
Agent	Parser/buffer that applies lag $L$ and creates $ca{p}_{m,t}^{obs}$
Application	Rolling MILP scheduler (Stage 2) that consumes $ca{p}^{obs}$ and re-optimizes

Table 4. Factorial design (σ, tr, λ, Δ, δ).

Factor	Symbol	Levels	Description
Capacity volatility	σ	{Low = 0.05, Medium = 0.10, High = 0.20}	Fractional standard deviation in available capacity across machines.
Transport delay	tr	{2, 5, 8 slots}	Average inter-tier transit time.
Stability penalty	λ	{0, 0.2, 0.5}	Weight applied to resequencing term in Equation (4).
Re-solve interval	Δ	{3, 5 slots}	Interval between rolling-window re-optimizations.
Freeze length	δ	{1, 2 slots}	Portion of window frozen for execution.

• Each unique combination of (σ, tr, λ, Δ, δ) defines one experimental run.
• Ten stochastic replications per setting (different random seeds) were performed to compute mean ± 95% confidence intervals.

6.2. Data Inputs

The testbed includes three Tier-1 families $\{S_1,S_2,S_3\}$ and two OEM families $\{O_1,O_2\}$. Table 5 reports their demands $Q_f$, approximate processing-time ranges $p_{f,m}$, eligible machines $M_f$, and setup times $s_{f,g,m}$. These parameters are used to generate all scenarios and performance metrics reported in Section 7.

Table 5. Product-family parameters (S1–S3, O1–O2).

Family	Type	Avg. Proc. Time (pf,m) [min/unit]	Demand (Qf)	Eligible Machines (Mf)	Setup (sf,g,m) [min]
S1	Tier-1	4–6	50	{M1, M2}	3
S2	Tier-1	5–7	60	{M2, M3}	3
S3	Tier-1	6–8	40	{M1, M3}	4
O1	OEM	8–10	70	{M4}	5
O2	OEM	9–11	65	{M5}	5

• Two tiers—one Tier-1 supplier and one OEM assembler.
• Five product families—{S1, S2, S3, O1, O2}. Each Tier-1 family supplies sub-components to one or more OEM families as defined in the precedence set P.
• Machine groups—M_S = {m_s1} for Tier-1 and M_O = {m_o1} for OEM. Each machine can process any family assigned to its tier with deterministic processing time p_f,m and stochastic availability cap^real{m,t}.

Random availability patterns were generated using Weibull (β = 1.8, η = 12) up/down durations; the planner only observed a delayed version cap^obs{m,t−L} depending on the information lag L = {0, 2, 5}.

Transport delays tr{f_s,f_o} followed a discrete uniform distribution U [1, 3].

Each replication used a distinct random seed sᵢ ∈ {1,…,10}.

6.3. Baselines

Three scheduling policies were compared:

• Static Plan (no feedback): The MILP is solved once at t = 0 with expected capacity \hat{cap}_{m,t} and executed open-loop.
• Rolling Deterministic Plan (reactive): The model is re-solved every Δ slots using deterministic forecast capacity without stability control (λ = 0).
• Two-Stage Stochastic Plan—Proposed: Incorporates observed capacity cap^{obs}_{m,t}, applies resequencing penalty λ > 0, and uses finite freeze δ to emulate practical rolling-window control. This configuration corresponds to the real-time scheduling environment depicted in Figure 1.
  

  Figure 1. Key challenges in smart manufacturing addressed by MTConnect.

6.4. Key Performance Indicators (KPIs)

Each run produces time-series data for backlog, utilization, and stability metrics. Final KPIs are defined mathematically as follows:

• Weighted tardiness (service level): We measure OEM service shortfall as the time-aggregated weighted backlog across all OEM families:

  $$WT={\displaystyle \frac{{\sum }_{f_o,t}{w}_{f_o}^{tard}\hspace{0.17em}bac{k}_{f_o,t}}{{\sum }_{f_o}{Q}_{f_o}}}$$

  (17)
• OEM idle time (coordination loss): We define OEM idle time as the fraction of available OEM capacity that is unused due to upstream constraints:

  $$Idle=1-{\displaystyle \frac{{\sum }_{f_o,m,t}{p}_{f_o,m}\hspace{0.17em}{x}_{f_o,m,t}}{{\sum }_{m,t}ca{p}_{m,t}^{real}}}$$

  (18)
• Machine utilization (efficiency):

  $$Util={\displaystyle \frac{{\sum }_{m\in M}{\sum }_{t\in T}{p}_{f,m}{x}_{f,m,t}}{{\sum }_{m\in M}{\sum }_{t\in T}ca{p}_{m,t}^{real}}}$$

  (19)
• Schedule deviation (stability):

  $$Dev={\displaystyle \frac{{\sum }_{f,m,t}\left|x_{f,m,t}-x_{f,m,t}^{prev}\right|}{{\sum }_{f,m,t}{x}_{f,m,t}^{prev}+1\times {10}^{-6}}}$$

  (20)
• Computation time per cycle (solvability): Average wall-clock time per re-optimization cycle, averaged across all solves in a run.

Average wall-clock time per MILP re-solve:

$$CPU={\displaystyle \frac{1}{N_{cycles}}}\sum _{k=1}^{N_{cycles}}{t}_k^{solve}$$

(21)

All KPIs were normalized to the range [0, 1] where appropriate to facilitate comparison across figures. The real-time data exchange framework used for buyer–supplier collaboration is illustrated in Figure 2.

Figure 2. Real-time data exchange framework for buyer–supplier collaboration via standardized IIoT hub.

7. Results

7.1. Overall Performance

The comparative analysis evaluates two variants of the proposed rolling two-stage MILP: (i) a real-time visibility policy (L = 0), where the planner observes machine availability without delay; and (ii) a lagged baseline (L = 5) in which the planner only observes capacity information five time slots late. Both variants share the same planning horizon, recourse logic, and stability weight $\lambda$; they differ only in the timeliness of the input capacity data.

For each disruption scenario (low, medium, high) and for each visibility setting, we run 10 independent replications on identical uptime/downtime sample paths over a 100-slot horizon with a 12-slot planning window. All reported KPIs are averaged across replications, with error bars indicating sample variability.

Section 6.3 defines three benchmark policies. In Section 7, we report detailed results for the real-time vs. delayed-visibility comparison because the central research question is the value of timely capacity visibility; benchmark comparisons are reported in Section 7.2.

Service-level impact:

Figure 3 reports the strict on-time fulfillment rate (OTFR_\text{strict}) for the rolling MILP scheduler as the information lag $L$ varies. For each $L\in \{0,2,5,8,10\}$, we run 10 replications on the same disruption and demand sample paths. The point at L = 0 corresponds to the real-time visibility policy, while $L=5$ represents the “No-standard’’ lagged policy used as the baseline in the main comparison. As $L$ increases beyond about 4–5 slots, the scheduler reacts to increasingly outdated availability, leading to an approximately 10–12% drop in OTFR_strict relative to real time (from ~0.75 to ~0.67) and higher variance across runs. The real-time policy (L = 0) achieves OTFR_strict ≈ 0.75 (mean across 10 replications).

Figure 3. Strict on-time fulfillment rate (OTFR_strict) versus information lag L.

Backlog behavior:

Figure 4 shows the total backlog (sample mean with 95% confidence interval) as the information lag $L$ increases. For each $L\in \{\mathrm{0,2},\mathrm{5,8},10\}$, 10 replications are plotted. Backlog increases sharply from L = 0 to L = 2, then continues to rise through L = 8 before leveling off at L = 10. The real-time policy corresponds to the marker at L = 0 in Figure 4. Comparing this point with the baseline lagged policy at $L=5$ shows that the mean cumulative backlog approximately doubles from ~380 at L = 0 to ~780 at L = 5–8, and variance increases substantially, illustrating how lagged information degrades both service and predictability.

Figure 4. Cumulative weighted backlog versus information lag L.

Multi-seed analysis:

Figure 5 and Figure 6 present aggregated OTFR_strict and backlog distributions across 10 random seeds. These confirm that real-time data improves service and reduces flow congestion consistently across stochastic runs, validating robustness.

Figure 5. OTFR_strict comparison: real-time (L = 0) versus lagged (L = 5), per replication.

Figure 6. Cumulative backlog comparison: real-time (L = 0) versus lagged (L = 5), per replication.

7.2. Comparison with Baseline Scheduling Policies

To position the proposed framework relative to simpler scheduling alternatives, Table 6 compares three policies under medium disruption (σ = 0.10) with 10 replications. The static plan solves the MILP once at t = 0 with expected capacity and executes open-loop without replanning. The rolling deterministic policy re-solves every Δ = 5 slots using observed capacity but without stability control (λ = 0). The proposed policy uses the full two-stage rolling MILP with λ = 0.2 and real-time visibility (L = 0). To the best of our knowledge, no directly comparable OEM–Tier-1 MILP benchmark exists in the literature; we therefore compare against static and rolling deterministic ablations of our own framework.

Table 6. Comparison of scheduling policies under medium disruption (σ = 0.10, Weibull up/down, 10 replications, mean ± std). OTFR_strict = fraction of OEM demand events with zero backlog.

Policy	OTFR_Strict	Backlog	OEM Idle	Sched. Dev.	Solve (s)	Improv. vs. Static
Static Plan (no feedback)	0.447 ± 0.306	22.2 ± 20.9	14.3 ± 16.0	N/A	0.10	-
Rolling Deterministic (λ = 0)	0.758 ± 0.077	0.0 ± 0.0	48.3 ± 24.2	206.0 ± 22.8	0.02	+69.6% OTFR
Proposed (λ = 0.2, L = 0)	0.754 ± 0.077	0.0 ± 0.0	33.7 ± 9.0	118.5 ± 16.5	0.03	+68.7% OTFR

Key findings: (1) Rolling re-optimization improves strict on-time fulfillment by approximately 70% relative to static planning and eliminates terminal backlog entirely. (2) The stability penalty (λ = 0.2) reduces schedule deviation by 42.5% and OEM idle time by 30% compared with the deterministic rolling policy, with negligible effect on OTFR (−0.5%). This confirms that the tunable stability weight achieves meaningful plan smoothness and improved OEM–Tier-1 coordination without sacrificing service performance. (3) All solve times remain well below one second per cycle, confirming real-time feasibility.

7.3. Stability vs. Agility

The trade-off between schedule stability and service responsiveness is governed by the stability-penalty coefficient λ in the Stage-2 MILP. A higher λ discourages resequencing, maintaining plan continuity but potentially allowing tardiness to accumulate; a lower λ promotes rapid adaptation to new information.

The λ-sensitivity experiment (λ ∈ {0.01, 0.1, 1.0, 5.0}) shows clear diminishing returns once λ reaches order-one values. As λ increases from 0.01 to 1.0, resequencing frequency drops by on the order of 40% (resequencing decreases monotonically as λ increases), while average weighted tardiness rises only slightly (roughly 5–10% on the plotted scale). In other words, a modest stability penalty is enough to substantially smooth the execution plan without materially degrading service performance. Beyond λ ≈ 1, further increases have little additional effect on either resequencing or tardiness, indicating a natural “sweet spot” where the agility–stability trade-off is well balanced.

While a formal dual analysis is beyond the scope of this paper, the λ-sensitivity experiment serves an analogous role: it reveals how the shadow price of schedule stability varies with the penalty weight. The diminishing-returns behavior observed in resequencing drops sharply for small λ but plateaus beyond λ ≈ 1, suggesting that the stability constraint is not tightly binding at moderate penalty levels, and that the system has sufficient scheduling flexibility to accommodate both service and stability objectives simultaneously. The resulting stability–agility trade-off is illustrated in Figure 7.

Figure 7. Stability–agility trade-off: schedule deviation (left axis) and cumulative backlog (right axis) versus stability weight λ (mean over 10 replications, L = 0, medium disruption).

7.4. Sensitivity to Replanning Interval and Disruption Severity

This experiment checks how fragile the OEM–Tier-1 schedule is when the environment becomes noisier (more frequent machine downtime/capacity loss). We kept the rolling-horizon logic (Δ, δ fixed as in Section 6) and re-ran the synthetic instances under three disruption settings: low, medium, and high (see Table 4 in Section 6). For each setting, we recorded two KPIs that directly reflect OEM–Tier-1 coordination:

• Weighted tardiness at the OEM proxy for service.
• OEM idle time proxy for how often the OEM is forced to wait for Tier-1 material.

Because all runs use the same MILP and the same precedence graph, any change in these two metrics is attributable to the disturbance level, not to the model.

Interpretation: Figure 8 shows a clear monotonic increase in cumulative backlog across disruption levels: low (~100), medium (~380), and high (~780). This confirms that as disruption intensity grows, the rolling scheduler encounters more capacity shortfalls that translate into unmet demand. The variance also increases with disruption severity, reflecting the greater uncertainty in production outcomes under frequent breakdowns.

Figure 8. Cumulative weighted backlog under different disruption levels (mean ± std, 10 replications).

Interpretation: OEM idle time decreases from low (~55) to medium (~34) to high (~22). This is counterintuitive at first but reflects the underlying capacity dynamics: under low disruption, machines are up more frequently, producing excess Tier-1 inventory while the OEM machine also runs smoothly, leaving more available-but-unused capacity. Under high disruption, OEM capacity itself drops substantially, so there is less total available time to register as idle. The key insight is that disruption severity shifts the bottleneck: under low disruption, the constraint is demand (idle capacity exists), while under high disruption, the constraint is capacity (every available slot is needed).

7.5. Family-Level Insights

Recall from Table 5 that $S_1,S_2,S_3$ denote the three Tier-1 product families, while $O_1$ and $O_2$ are the two OEM assembly families that consume those components. Family-level Gantt charts help visualize how disruptions propagate through the OEM–Tier-1 hierarchy.

In Figure 9 and Figure 10, S1–S3 and O1–O2 refer to the product families defined in Table 5. The Gantt views focus on a representative Tier-1 machine (ms1) and OEM machine (mo1), but all five families and their demands are those of Table 5.

Figure 9. OEM idle time under different disruption levels (mean ± std, 10 replications).

Figure 10. Gantt chart: real-time coordination (L = 0), window t = 11–23.

Figure 10 shows a real-time (L = 0) scheduling window t = 11–23. Both Tier-1 machines (MS1, MS2) are actively producing supplier families S1–S3, while the OEM machine (MO1) runs O1 and O2 assemblies with only brief idle gaps coinciding with machine downtime (shaded in pink). The tight coordination between tiers is visible: production blocks are dense and gaps are minimal.

Figure 11 shows a lagged (L = 5) scheduling window t = 21–33. The Tier-1 machines show larger idle stretches (notably MS1 at t = 21–24), and the OEM machine has a hatched idle gap at t = 21–22, where the planner scheduled production based on outdated capacity data but the machine was actually down. This illustrates directly how information lag causes the planner to misallocate capacity, resulting in idle gaps and delayed Tier-1 production that propagates to OEM waiting.

Figure 11. Gantt chart: lagged scheduling (L = 5), window t = 21–33.

At later stages, lagged updates cause the OEM to operate on outdated component data, introducing idle gaps and backlog spikes.

These results confirm that coupling constraints amplify lag effects non-linearly: small Tier-1 delays can produce multi-slot OEM idle periods.

Consistent with Table 5, S1–S3 represent three component families at Tier-1 that feed two OEM assemblies O1 and O2. When Tier-1 production of S1–S3 is delayed, the dependent OEM families (especially O2) experience idle waiting, as shown in Figure 11.

7.6. Computational Efficiency

Each MILP instance averaged under 0.1 s solve time (HiGHS solver) with a < 1% optimality gap at termination. As reported in Table 6, the static plan solves in approximately 0.10 s, while rolling re-optimizations average 0.02–0.03 s per cycle.

The problem size scaled with horizon H and families |F| as follows:

$$\mathrm{Variables}\approx \mathrm{12,000}+500\mid F\mid ,\mathrm{Constraints}\approx \mathrm{10,000}+400\mid F\mid$$

Even under the highest-disruption scenario (H = 12, Δ = 5, |F| = 6), replanning remained real-time-feasible on a standard i7 processor. This confirms the suitability of the proposed MILP-based scheduler for near-real-time decision support in OEM–Tier-1 coordination.

To assess scalability, we note that the core model has approximately O(|F|·|M|·H) continuous variables and O(|F|·H + |M|·H) constraints per rolling window. For our testbed (|F| = 5, |M| = 3, H = 12), this yields ~180 variables and ~200 constraints trivially solvable. Scaling to an industrial instance with |F| = 50 families, |M| = 30 machines, and H = 20 yields ~30,000 variables and ~4000 constraints, which remains well within the capability of modern LP/MILP solvers (seconds on commodity hardware). Beyond ~100 machines with setup binaries enabled, decomposition strategies such as Benders decomposition (by tier) or Lagrangian relaxation (by machine) would likely be needed to maintain sub-second solve times. Compared with metaheuristic or reinforcement learning approaches, the MILP formulation offers the advantage of provable optimality within each window, interpretable solutions, and no training overhead at the cost of scalability limits on very large instances. We view the two paradigms as complementary: MILP for moderate-scale problems with interpretability requirements, and learning-based methods for large-scale or highly dynamic settings where near-optimal solutions suffice. The computational scalability trend across increasing problem sizes is shown in Figure 12.

Figure 12. Computational scalability: average solve time per rolling-horizon cycle across increasing problem sizes. The dashed line indicates the 1 s real-time threshold.

8. Discussion

8.1. Theoretical Implications

This work shows that a two-stage, time-indexed MILP can sit right in the middle of the usual scheduling spectrum:

• At one end, classic robust/static models protect against uncertainty but do not react once the plan is released.
• At the other end, purely dynamic/dispatching rules react fast but lose global optimality and Tier-1 ↔ OEM coordination.

Our formulation does both: Stage 1 gives a globally consistent plan under expected capacity, and Stage 2 re-optimizes on the actually observed (possibly delayed) capacity stream while charging a penalty for resequencing (the λ ∑ z term). That makes the model a concrete, MILP-based instantiation of a “stable but reactive” scheduler for two-tier supply settings. The experiments also support the idea that family-level aggregation is a good surrogate for large mixed OEM–supplier systems: once parts with similar process plans are grouped, the number of time-indexed binaries drops, but we still retain the precedence and transport logic between tiers. In other words, the paper provides an explicit way to embed material-availability constraints (Tier-1) inside a capacity-constrained OEM scheduler without going to full-blown multistage stochastic programming.

The value of Stage 1 extends beyond simple initialization. By solving the full-horizon problem under expected capacity, Stage 1 provides a globally coordinated baseline that accounts for cross-tier precedence, transport delays, and demand patterns over the entire planning window. Stage 2 then adapts this plan to observed capacity while penalizing deviations from the Stage-1 baseline. Without Stage 1, the stability penalty in Stage 2 would have no reference plan, and the optimizer would resequence freely at each cycle, defeating the purpose of the λ control. In effect, Stage 1 anchors the rolling scheduler to a coordinated plan, while Stage 2 provides reactive adaptation. The risk of error propagation is mitigated by the rolling horizon: Stage-1 forecasts are only used for one planning window (H = 12 slots) before being refreshed, limiting the duration over which forecast errors can compound.

We acknowledge that the individual elements of this framework—two-stage stochastic programming, rolling-horizon re-optimization, and stability penalties—are individually well-established in the scheduling literature. The theoretical contribution of this work is not a new optimization method per se, but rather a novel integration of these elements for a specific, underexplored problem context: joint OEM–Tier-1 family scheduling with explicit information lag and tunable resequencing control. This integration is non-trivial because the cross-tier material coupling (Equation (10)), the planner-vs-execution capacity split under lag L, and the stability–agility trade-off via λ interact in ways that do not arise in single-tier formulations. The framework provides three properties that, to our knowledge, have not been jointly demonstrated in prior work: (i) the MILP remains tractable under rolling re-optimization (solve times < 0.1 s), (ii) the stability penalty provably reduces schedule deviation without materially degrading service (Table 6), and (iii) the information lag L creates a quantifiable, monotonic degradation in OTFR (Figure 3). While we do not provide formal optimality bounds or convergence proofs, which would require assumptions on the stochastic capacity process that our protocol-agnostic design deliberately avoids, the controlled experimental evidence consistently supports these properties across 10 replications and three disruption levels.

8.2. Managerial Implications

These results complement earlier conceptual work on open, data-driven manufacturing ecosystems by showing that, once streaming data are available, a relatively compact MILP can translate that visibility into tangible improvements in OEM–Tier-1 coordination:

• Share only availability/status, not full models. Our runs used exactly the kind of data MTConnect (or any lightweight shop-floor connector) can expose: machine up/down, completion counts, and time stamps. That is enough to refresh the OEM plan. Suppliers do not need to publish full routings, rates, or costs—a realistic data-sharing posture for automotive, aerospace, or electronics supply chains.
• Pick Δ first, then tune λ. Results showed that once Δ is “short enough” to see disruptions (5–8 slots in our testbed), changing λ controls the behavior of the plan, not the service level: small λ → very agile, more resequencing; larger λ → calmer plan with slightly more backlog. So, in practice,
  • Choose Δ from IT/operations constraints (how often you can poll MTConnect/re-solve);
  • Then increase λ until the rescheduling noise is acceptable for supervisors.
• Family-level planning = simpler conversations. Because decisions are on $(f,m,t)$ and not on every individual job, planners can talk to suppliers and OEM lines in family terms (“run S2 for the next 3 slots”, “hold O1 until S3 arrives”), which is exactly what we showed in the two Gantt windows (early supplier push vs. OEM waiting). This is easier to explain and to override manually than a job-by-job schedule.
• OEM idle time is the right KPI for cross-tier alignment. Even when weighted tardiness stayed near zero across disruption levels, OEM idle time still reacted. That metric is what managers should watch when they debate “is more frequent replanning worth it?”.

8.3. Limitations

This study is deliberately controlled, and that sets three clear boundaries:

• Emulated data, not plant logs: Machine availability was generated from Weibull-style up/down processes and then delayed; real MTConnect streams will have missing tags, late heartbeats, and operator overrides. So the logic is field-ready, but the parameters will need tuning on live data.
• MILP scalability: The two-stage model solved comfortably for our horizon, five machines, and five families. A 30-machine, multi-plant case with lot-sizing and sequence-dependent setups will need decomposition (rolling + facility-by-facility solves, or fix-and-optimize). That should be stated upfront for industrial readers.
• Deterministic processing and transport: We assumed known $p_{f,m}$ and fixed transport delays. In practice, both are noisy. The current model can buffer that uncertainty (shorter Δ, slightly higher safety λ), but it does not model it. Extending the recourse stage to chance-constraints or to interval capacities is a natural follow-up.
• Fourth, the framework does not provide formal optimality bounds or convergence guarantees. The rolling-horizon approach solves a finite-horizon MILP at each cycle, and optimality of the full-horizon solution is not guaranteed due to the myopic nature of rolling re-optimization. Establishing such bounds would require assumptions on the stochastic capacity process (e.g., Markovian structure) that our protocol-agnostic design deliberately avoids. Future work could explore performance bounds under specific distributional assumptions.
• Fifth, the current model treats information lag L as a deterministic, fixed parameter. In practice, network delays are stochastic and may vary by machine, time of day, or protocol. Packet loss, missing data, and noise measurement are also common in real MTConnect/OPC UA deployments. The framework could accommodate stochastic L by treating it as a random variable and averaging over realizations, or by using robust capacity bounds. Similarly, missing data could be handled by imputing last-known capacity values, a simple extension compatible with the current architecture. These extensions are left for future work.

That closes the argument of the paper: a two-tier manufacturer can get most of the benefit of real-time visibility with a rolling two-stage MILP, provided it stays at family level, refreshes often, and penalizes plan churn.

9. Conclusions

This study presented a protocol-agnostic, real-time scheduling framework for a vertically coupled OEM–Tier-1 manufacturing network. Using a two-stage MILP architecture, the model integrates family-level aggregation, rolling-horizon replanning, and stability penalization to capture both agility and coordination in uncertain production environments. The formulation remains data-source-neutral. It can use MTConnect or any equivalent protocol for streaming machine availability and job status, making it adaptable to different industrial settings.

Returning to the research questions posed in Section 2.2, the experimental results provide the following answers. RQ1 (effect of real-time visibility): Figure 3 confirms that OTFR_strict decreases monotonically from ~0.75 at L = 0 to ~0.67 at L = 8–10, supporting hypothesis H1. RQ2 (stability penalty): Figure 7 and Table 6 demonstrate that increasing λ from 0 to 0.2 reduces schedule deviation by 42.5% with negligible impact on OTFR (−0.5%), supporting H2. RQ3 (comparison with baselines): Table 6 shows that the proposed rolling two-stage MILP improves OTFR by approximately 70% over static planning and eliminates terminal backlog, supporting H3.

The experiments using synthetic OEM–Tier-1 datasets demonstrated measurable performance improvements. The proposed method consistently reduced weighted tardiness and OEM idle time across varying disruption intensities while maintaining schedule stability. The λ-penalized two-stage MILP achieved a balance between service level and resequencing frequency, providing a tangible trade-off curve between responsiveness and plan stability. Moreover, family-level aggregation proved computationally efficient, enabling re-optimization within practical time limits even under rolling-horizon operation.

Looking ahead, the framework can be extended in three major directions:

• Integration with live MTConnect feeds to validate the system using real industrial data streams.
• Expansion to multi-tier networks to capture deeper supply chain dependencies beyond Tier-1.
• Coupling with predictive maintenance and hybrid AI solvers, such as reinforcement learning or neural surrogate models, to anticipate disruptions before they occur and guide MILP warm starts.

Together, these advances would make the proposed architecture a scalable foundation for autonomous, data-driven scheduling in the next generation of smart and resilient manufacturing systems.

10. Future Work

Building on the validated two-stage MILP framework, several extensions are envisioned to push this research closer to industrial deployment and scientific generalization.

Integration with MTConnect and digital twins: A natural next step is to embed the model within an MTConnect-driven digital twin of the OEM–Tier-1 network. Real-time data ingestion, semantic labeling of events, and virtual commissioning can close the loop between scheduling, execution, and feedback [5,6,12,13,25,29]. This will allow the scheduler to operate continuously using live status tags (avail, execution, completion), enabling direct validation of responsiveness, latency, and communication overhead.

Multi-objective optimization: Future versions can evolve from the single-objective cost and stability trade-off toward a multi-objective formulation that simultaneously minimizes tardiness, energy consumption, and carbon footprint. Such a framework will align with sustainability goals and Industry 5.0 priorities. Weighted or Pareto-front analysis could reveal how environmental and operational objectives interact in real-time manufacturing environments [33].

Human-in-the-loop decision support: Although the current scheduler operates autonomously, practical adoption will benefit from a human-in-the-loop layer, where planners can visualize conflicts, override assignments, or adjust λ and Δ interactively [34,35,36]. This would bridge mathematical optimization and managerial decision-making, ensuring trust and usability in high-stakes operations.

Learning-enhanced optimization: Finally, reinforcement learning and surrogate modeling offer a path to policy improvement over time. A reinforcement agent could learn optimal λ-adjustment or warm-start heuristics for the MILP solver based on disruption history and system feedback [31,32,35,36,37,38,39,40,41]. This hybridization combining prescriptive optimization with adaptive learning would make the scheduler progressively more predictive, resilient, and self-improving in a real manufacturing ecosystem.

Together, these directions pave the way for a data-driven, explainable, and sustainable scheduling architecture, advancing toward fully autonomous, connected, and intelligent production networks in line with next-generation smart manufacturing and resilient production systems.