Maintenance Cessation: Definitions and Models

• Maintenance cessation is defined as the deliberate termination of maintenance interventions across diverse domains, including industrial, software, and IoT systems.
• Modeling approaches employ optimal stopping theory, deep reinforcement learning, and Markov decision processes to determine the most cost-effective and safe cessation points.
• In digital ecosystems, cessation extends to explicit end-of-maintenance events, where archival status and vendor discontinuation underline critical socio-technical dependencies.

Searching arXiv for the specified papers to ground the article in current records. arxiv_search query: (Khorasgani et al., 2021) arxiv_search({"query":"(Khorasgani et al., 2021)","max_results":5}) Maintenance cessation denotes the termination, withholding, or explicit end of maintenance-related intervention, but its referent is strongly domain-dependent. In industrial asset management, it commonly appears as a stopping decision: continue operation or cease operation and repair, or equivalently choose the stopping time at which maintenance should be performed before failure (Khorasgani et al., 2021, Saporta et al., 2011). In software ecosystems, it is an event-level state in which maintenance has ended, grounded in repository archival status or explicit cessation statements in project documentation (Xu et al., 29 Jul 2025). In cloud-dependent IoT systems, manufacturer cessation can induce maintenance cessation because the device’s essential functions, updates, and support infrastructure are structurally tied to the vendor’s continued existence (Schip, 2024). In large engineered facilities such as DEMO fusion plants, the relevant notion is often the maintenance outage itself: the period during which the plant must stop generating power so that scheduled maintenance can be executed (Crofts et al., 2014).

1. Operational meanings across maintenance literatures

In maintenance decision-making for degrading equipment, cessation is a binary operational action. One formulation defines the learned policy over historical trajectories so that, at each time step, it chooses either “continue operation” or “repair the equipment,” with the intended behavior being to cease operation before failure when that yields higher long-term profit. In that setting, “An action is optimal if it leads to the maximum profit,” and profit is “the difference between the generated revenue and the operating costs,” including maintenance/repair costs and failure costs (Khorasgani et al., 2021).

In stochastic predictive maintenance for corrosion, cessation is instead the stopping of waiting. The decision variable is a stopping time $\tau$ at which full replacement maintenance is performed on a metallic structure subject to corrosion. The tradeoff is explicit: intervening too early is “uselessly costly,” while intervening too late risks reaching a critical thickness-loss threshold at which the structure is unusable. In the corrosion example, the unusable threshold is a thickness loss of $0.2$ mm (Saporta et al., 2011).

In condition-based maintenance with scheduled opportunities (SOs) and unscheduled opportunistic opportunities (USOs), cessation is local and state-dependent rather than terminal. The paper’s central stopping question is whether to withhold preventive maintenance at a given opportunity. “Ceased” at an opportunity means that the optimal policy chooses do nothing at that SO or USO because the expected marginal benefit of preventive maintenance is below its cost, given the remaining time until the next SO and the success probability of maintenance (Drent et al., 2019).

In open source software, the concept is formalized as an explicit end-of-maintenance event. A repository is considered to have reached maintenance cessation if and only if it is marked “archived” on GitHub or its top-level documentation contains direct statements such as “no longer maintained,” “deprecated,” “unmaintained,” or “end-of-life.” This definition is designed to avoid equating cessation with mere inactivity (Xu et al., 29 Jul 2025).

For cloud-dependent IoT, maintenance cessation can be a consequence rather than a maintainer decision. The argument is that when the manufacturer ceases operations, the cloud service disappears as well, leaving the device no longer updateable, supportable, or even usable; the maintenance function has therefore effectively ceased because it was structurally tied to the manufacturer’s continued existence (Schip, 2024).

These uses indicate that maintenance cessation is not a single universal construct. A plausible implication is that any rigorous analysis must begin with an operational definition specifying whether cessation means a stop-vs-continue action, an optimal stopping time, a temporary deferral, an outage interval, or an explicit end-of-support event.

2. Stopping-time formulations and policy structure

A large part of the technical literature treats maintenance cessation as a control problem. In offline supervised deep reinforcement learning for maintenance, the policy is learned from offline trajectories of observations $o_k$, actions $a_k$, and rewards $r_k$. For a sliding window of length $T$, the history variables are

$$O^T_k=\{o_{k-T+1},\ldots,o_k\}, \qquad A^T_{k-1}=\{a_{k-T},\ldots,a_{k-1}\},$$

with future cumulative rewards over a horizon $H$ defined by

$$r^H_k=\sum_{i=k}^{k+H} r_i, \qquad R^H_k=\{r^H_{k-T+1},\ldots,r^H_k\}.$$

The action predictor is

$\hat a_k = model(O^T_k, A^T_{k-1}, R^H_k),$

or, if remaining useful life is available,

$0.2$0

At deployment, each trajectory is treated as an episode, ending when the trajectory ends naturally, the equipment fails, or the equipment is sent for repair. The paper additionally imposes the practical stopping constraint that “repair decisions should be made at least 10 cycles before failure occurs,” so cessation is explicitly a safe pre-failure action (Khorasgani et al., 2021).

The corrosion study models the maintenance decision as an optimal stopping problem for a piecewise-deterministic Markov process (PDMP). With admissible stopping times

$0.2$1

the objective is

$0.2$2

The recursive dynamic-programming representation is

$0.2$3

This formulation makes the cessation decision equivalent to selecting the stopping time that maximizes expected reward before the structure becomes unusable (Saporta et al., 2011).

The scheduled/opportunistic maintenance model uses a semi-Markov decision process whose state space includes condition, opportunity type, and residual time to the next SO:

$0.2$4

Its main structural result is a control-limit policy depending on the remaining time until the next SO. In state 2 the policy is always “do nothing.” In state 1, preventive maintenance at a USO is optimal only when the residual time belongs to an interval $0.2$5; if the next scheduled maintenance is sufficiently close, it is optimal to defer and do nothing (Drent et al., 2019).

Across these models, cessation is not equivalent to failure. It is a decision rule over histories, states, or residual lifetimes, optimized under profit, cost, or reward objectives.

3. Economic thresholds, lead times, and near-failure intervention

The economics of cessation are organized around asymmetric costs. In the offline reinforcement-learning case study, the reward structure assigns positive reward to continued operation, negative reward to repair, and a large negative reward to failure. The specific experimental costs are failure cost $0.2$6, repair cost $0.2$7, and operating profit per cycle $0.2$8. Because failures are much more expensive than repairs, the policy should ideally stop the asset before failure when the expected long-term return is better. The case study on NASA C-MAPSS F002 shows this tradeoff directly: on the first test dataset, “No action” leads to an average cumulative reward of about $0.2$9, the ideal policy that repairs 10 cycles before failure achieves about $o_k$0, and using estimated RUL instead of true RUL gives about $o_k$1. The main reported takeaway is that the best policy is to continue until close to failure, then cease operation and repair, ideally about 10 cycles before failure in that setup (Khorasgani et al., 2021).

In the corrosion study, the reward function is piecewise affine in thickness loss and reaches its maximum around $o_k$2 mm, below the unusable threshold of $o_k$3 mm. The paper notes that, for the chosen reward, the true optimal stopping time is the first time the loss reaches $o_k$4 mm. Simulations show that the numerical policy typically stops in the interval $o_k$5, with tighter concentration as the discretization improves (Saporta et al., 2011).

The scheduled/opportunistic maintenance model makes the threshold structure depend on cost ratios and imperfect maintenance. Preventive maintenance is compared against corrective-maintenance cost $o_k$6, scheduled preventive-maintenance cost $o_k$7, unscheduled preventive-maintenance cost $o_k$8, and maintenance success probability $o_k$9. If the next cheaper scheduled opportunity is near, it is often optimal to withhold preventive maintenance at the USO; if it is far away, acting immediately becomes more attractive. The paper’s managerial message is therefore explicit: do not automatically use every maintenance opportunity (Drent et al., 2019).

Taken together, these results show that maintenance cessation is usually a near-failure but pre-failure decision. A plausible implication is that the crucial modeling variable is not degradation alone, but degradation filtered through future opportunity structure, cost asymmetry, and the reliability of the maintenance action itself.

4. Maintenance cessation as outage duration in large engineered systems

In fusion-power maintenance planning, cessation is measured less as a binary decision and more as elapsed offline time. The DEMO study treats the period during which the plant must stop generating power for scheduled remote maintenance as the practical counterpart of maintenance cessation. Plasma-facing components require frequent replacement because of erosion and very high neutron flux, and the duration of these interruptions directly affects availability and commercial viability (Crofts et al., 2014).

The study develops a bottom-up, modular maintenance-duration estimation tool based on the EFDA DEMO WP12 pre-conceptual design. The workflow begins with the vertical maintenance system using all sixteen upper ports for blanket removal and all sixteen divertor ports for divertor cassette removal. Port preparation includes removing the shield plug, deploying a pipe-joint cask, cutting and removing pipe elbows, and removing the port flange. Blanket replacement uses a vertical maintenance crane and an in-vessel mover; divertor replacement uses divertor transport casks and a cassette mover. The model estimates duration by assigning times to sub-tasks such as welding, bolting, cask docking, component extraction, and transport, then summing them for different maintenance scenarios (Crofts et al., 2014).

The model also incorporates recovery delays and logistics bottlenecks. Significant remote-handling failures on the critical path are assigned recovery durations, and transporter queuing is estimated with an $a_k$0 model. Reported transporter delays are less than 1% of total maintenance duration because the job service time is about 30 minutes, whereas remote-handling equipment failures account for approximately 20% of the total maintenance duration (Crofts et al., 2014).

Quantitatively, replacing blankets and divertor cassettes for a single sector is estimated to take close to 1000 hours. Full plasma-facing-component replacement takes about 22 months with a single remote-handling system, while four systems can complete the work in about 6 months. Under a planning scenario with a 1-month cooldown before maintenance and a 1-month conditioning/pump-down afterward, the estimate suggests that four remote-handling systems operating in parallel would be needed to meet the 75% availability target; the representative cycle given is two 24-month operating periods within a 62-month cycle, corresponding to about 77% availability (Crofts et al., 2014).

Here, maintenance cessation is not the end of maintenance but the interval of enforced non-operation caused by maintenance. That distinction is central in high-availability systems.

5. Explicit cessation in software repositories and IoT ecosystems

In OSS repositories, maintenance cessation is modeled as a longitudinal event suitable for survival analysis. The repository-level definition is dual-signal: archival status on GitHub or explicit cessation language in documentation. To confirm semantic cessation statements, the study uses a hybrid labeling pipeline comprising keyword-based candidate retrieval, manual annotation of 1,200 repositories by two annotators with Cohen’s $a_k$1, a SetFit classifier trained on 600 samples and validated on 600 samples, and LLM-assisted scaling. SetFit achieves Accuracy $a_k$2, Recall $a_k$3, and Precision $a_k$4; among the evaluated LLMs, GPT-4o performs best with Accuracy $a_k$5, Precision $a_k$6, Recall $a_k$7, and $a_k$8. GPT-4o labels the remaining 37,065 samples, and disagreements with SetFit are manually reviewed. The resulting dataset contains 115,466 GitHub repositories and 57,733 confirmed maintenance cessation events (Xu et al., 29 Jul 2025).

Prediction is built on an integrated feature framework combining user-centric, maintainer-centric, and project-evolution features, alongside surface features. User-centric features arise from a weighted bipartite user–repository graph with interaction weights star $a_k$9, commit $r_k$0, fork $r_k$1, and issue $r_k$2, with commit weight further scaled by log(lines changed). Influence is propagated by mutually reinforcing scores

$r_k$3

with percentile-rank and z-score normalization used to handle long tails. Maintainer-centric features include latest_maintainer_activity_interval, avg_response_time, and response_decay_trend; project-evolution features include contributor diversity computed as $r_k$4 Gini index, balance index, activity deviation, and feature/bugfix ratios. The best AFT survival model using all features achieves Harrell’s C-index $r_k$5 and Uno’s C-index $r_k$6, outperforming the surface-only baseline of $r_k$7 and $r_k$8, respectively. In deployment, the openEuler mapping pipeline matches 14,284 of 16,888 packages to GitHub repositories, for 84.6% coverage (Xu et al., 29 Jul 2025).

In IoT, the maintenance problem is shifted from repository state to infrastructural dependence. The regulatory analysis argues that European product and cybersecurity law has a blind spot for manufacturer cessation. Because many consumer IoT devices depend on cloud services for data analysis, authentication, access control, app mediation, device management, security patching, and compatibility, manufacturer cessation can leave consumers with devices that are unsupported, partially functional, or entirely defunct. The paper uses VanMoof e-bikes, Gigaset smart cameras, Insteon, and Jibo as examples, and identifies three properties for legislative solutions: pre-emptive measures, manufacturer-independent control, and collective control. Interoperability and open-source publication or escrow are treated as the main routes to continuity after the manufacturer disappears (Schip, 2024).

Software and IoT studies therefore move maintenance cessation from a purely technical degradation problem to a socio-technical one. This suggests that, in digital systems, cessation is often governed as much by maintainership, governance, and platform dependency as by artifact-level condition.

6. Boundary conditions, contrasts, and common misconceptions

One recurrent misconception is that automation implies cessation of maintenance work. The software-maintenance agenda on migration-based maintenance does not make that claim. It explicitly states that migration-based maintenance is “the process of reusing concrete maintenance operations (e.g., patches, tests, configuration updates) that have already been applied in other systems and adapting them to the target project,” and its overall framing is augmentation plus partial automation rather than total cessation of maintenance (Chen et al., 15 Feb 2026).

A second misconception is that every technical use of “cessation” is maintenance-specific. In dendrochronology, “stem-growth cessation events” in Picea crassifolia are identified through locally-absent rings and are driven primarily by low June precipitation and exacerbated by high July vapor pressure deficit; this is a moisture-stress phenomenon, not a maintenance decision (Zhao et al., 2017). In analytical mechanics, “sudden cessation” in circular motion refers to release of the central attachment in a massive spring/string system and the resulting immediate post-release trajectory (Batista, 2023). In rheology, cessation of steady shear or extensional flow in the affine linear Phan–Thien–Tanner model leads to exact stress-relaxation laws after the imposed deformation rate is switched off (Shogin, 2020).

These contrasts matter because they delimit the encyclopedia meaning of maintenance cessation from the broader technical vocabulary of cessation. A plausible implication is that the term should not be treated as self-explanatory: in any research context, its meaning depends on whether the object that ceases is operation, preventive intervention, repository support, cloud service continuity, or simply a physical or biological process.