Consecutive-Working Menu in RWS Scheduling

• The Consecutive-Working Menu is a scheduling component that enforces minimum and maximum consecutive workday limits in N-shift rotational workforce scheduling, ensuring compliance with labor standards.
• It integrates with a two-phase algorithm that first generates valid Boolean shift arrays and then assigns specific shift labels, using constraint propagation to prune infeasible candidates.
• The tool features a real-time user interface for validating scheduling parameters, ensuring that constraints like rest periods and staffing needs are rigorously met.

A Consecutive-Working Menu is a user interface component embedded in computer-aided systems for generating N-shift rotational workforce schedules (RWS), enabling explicit specification and enforcement of minimum and maximum consecutive working day constraints. In the context of shift scheduling algorithms, notably as described by Bolling (2021), this menu plays a central role in constraint-driven search and pruning, ensuring that all generated candidate schedules adhere rigorously to user-defined blocks for consecutive workdays while satisfying multifaceted staffing and labor regulations (Bolling, 2020).

1. Role within the N-shift RWS Scheduling Framework

The N-shift RWS generator incorporates a two-phase procedure: (i) enumeration of feasible Boolean shift-arrays representing working/off days, then (ii) construction of fully-labeled rotational schedules that assign concrete shift types. The consecutive-working menu introduces the parameters $L_{\min}$ (minimum consecutive working days) and $L_{\max}$ (maximum consecutive working days), which directly modulate both phases.

Key input variables of the scheduling problem include:

• $N$: Number of shifts per day.
• $t_s$: Length of a shift.
• $t_W$: Target weekly working hours per employee.
• $n_{wd}$: Working-day slots per week.
• $n_W$: Number of weeks in the cycle (equal to the number of employees).
• $t_r$: Minimum continuous rest per week.
• $n_{cf}$: Optional clustering for days off.
• $L_{\min}$, $L_{\max}$0: Minimum and maximum span of consecutive workdays.
• $L_{\max}$1: Staffing requirements for shift $L_{\max}$2 on day $L_{\max}$3.

The menu's role is to allow the schedule maker—via a graphical user interface—to specify $L_{\max}$4 and $L_{\max}$5, which are then actively propagated throughout both combinatorial and labeling stages of the generation process (Bolling, 2020).

2. Mathematical Specification of Consecutive-Working Constraints

Let $L_{\max}$6 denote the shift assigned to employee $L_{\max}$7 on day $L_{\max}$8, with $L_{\max}$9, and define the indicator $N$0 if $N$1, $N$2 otherwise.

Run-Length Constraints:

For each employee $N$3 and for all valid starting days $N$4:

$N$5

This ensures that every run (block) of consecutive 1’s (workdays) satisfies the prescribed minimum and maximum lengths.

Other relational constraints include:

• Weekly working-hours: $N$6 for all weeks $N$7.
• Minimum rest: For adjacent worked shifts, rest intervals between end/start times must be at least $N$8.
• Staff coverage: $N$9 for each day-shift pair.

3. User Interface and Validation Procedures

The GUI exposes numeric entry fields for both "Min consecutive working days" ($t_s$0) and "Max consecutive working days" ($t_s$1) under the dedicated "Sequence-Length Constraints" section. Validation logic is enforced in real time:

• $t_s$2
• $t_s$3
• Error flags are triggered if $t_s$4 or $t_s$5, and the "Generate" operation is disabled until all values are consistent.

Upon user confirmation, the algorithm integrates these parameters into its combinatorial search, directly filtering candidate arrays that violate the run-length bounds before schedule labeling begins (Bolling, 2020).

4. Algorithmic Integration and Pruning Strategies

Two algorithmic phases harness the menu constraints:

• Phase 1 (Boolean Array Generation): Constructs all 0–1 vectors of length $t_s$6 with exactly $t_s$7 ones per employee per week, discarding any with runs of 1’s outside $t_s$8. Constraint propagation is applied throughout, immediately pruning partial solutions upon run-length or coverage violation.
• Phase 2 (Shift Labeling): Each survivor array is transformed by labeling the 1’s with specific shift types ($t_s$9). The space is traversed via full Cartesian product—if tractable—or recursive backtracking that promptly abandons any partial labeling which breaches rest, coverage, or run-length constraints.

This bidirectional enforcement ensures every presented solution respects the block sizes for consecutive working days as set by the user.

Algorithmic Stage	Constraint Usage	Pruning Mechanism
Boolean Array Generation	$t_W$0, $t_W$1	Reject partial/candidate arrays violating run-length bounds
Shift Type Labeling	$t_W$2, $t_W$3, $t_W$4, $t_W$5	Backtrack if extension fails local checks

Theoretical complexity for Phase 1 is $t_W$6, but practical runtime is reduced via early constraint filtering. Empirical benchmarks yield full generation times $t_W$7s for cycles up to $t_W$8 on commodity hardware (Bolling, 2020).

5. Concrete Example and Validation

For instance, selecting $t_W$9 shifts per day (Day, Evening), $n_{wd}$0, $n_{wd}$1, $n_{wd}$2h, $n_{wd}$3h ($n_{wd}$4), $n_{wd}$5h, $n_{wd}$6, $n_{wd}$7, $n_{wd}$8, yields Phase 1 menu settings:

• Min consecutive working days = 3
• Max consecutive working days = 5

A Boolean array for a single employee in Phase 1: 1 1 1 1 0 0 0 1 1 1 0 0 0 0 1 1 1 1 1 0 0 0 0 1 1 1 1 0

All runs of 1’s are in $n_{wd}$9, with exactly 5 working days per week. In Phase 2, a corresponding labeled schedule might be:

$n_W$0

The GUI highlights valid consecutive blocks in green. If any assignment would produce, for example, a two-day run of work, the week is flagged in red and correction is enforced, maintaining strict compliance with the consecutive-working constraints (Bolling, 2020).

6. Significance, Limitations, and Extensions

By elevating $n_W$1 and $n_W$2 to first-class constraints, the Consecutive-Working Menu enables granular control over labor fairness and fatigue mitigation, consistent with operational realities. This approach differs from generic cost-based optimization by presenting the entire feasible set under explicit run-length controls rather than privileging single optimal solutions.

A plausible implication is that while this menu-driven, constraint-pruning methodology facilitates robustness and transparency, it can become computationally demanding for large $n_W$3 due to combinatorial explosion, despite aggressive pruning and empirical tractability for moderate cases ($n_W$4). The system does not optimize an explicit cost function but enumerates all feasible candidate arrangements, thus prioritizing conformance and user flexibility over optimization (Bolling, 2020).