Charging-aware scheduling (CARTOS)

"A deadline is a promise about time. On this device, time is something I have to buy back from the sun before I can spend it."

A Patient AI Agent

This section assumes the harvesting and storage physics of Section 63.1, the checkpoint-and-resume execution model of Section 63.2, and the per-inference energy knob of Section 63.3. Where 63.3 answered "how big a model can I run now", this section answers "in what order, and at what time, should I run a whole set of sensing, inference, and radio tasks so the important ones finish on time". Because the answer depends on anticipating future harvest, it also leans on the timekeeping and synchronization ideas of Chapter 3 (a scheduler needs a clock that survives power loss) and the estimation toolkit of Chapter 4 (forecasting the next charge interval is an estimation problem).

The charge-then-execute task model

Model the workload as a set of tasks, each with an energy cost \(e_i\), a worst-case execution time \(c_i\), a release time, and a deadline \(d_i\). On a battery device you would schedule these with a classical real-time policy such as earliest-deadline-first (EDF), reasoning only about time. On a batteryless device a task cannot start until the capacitor holds at least \(e_i + E_{\text{reserve}}\), and the time to reach that level is set by the harvester, not by the scheduler. So each task is really a pair: a charge phase of duration

$$ t^{\text{charge}}_i \;=\; \frac{e_i + E_{\text{reserve}} - E_{\text{now}}}{P_{\text{harvest}}}, $$

followed by an execute phase of duration \(c_i\). The charge phase can be far longer than the execute phase: harvesting a few millijoules from a dim indoor cell can take seconds, while the inference it powers runs in milliseconds. The scheduling problem is therefore dominated by the term the classical theory ignores. A task is schedulable only if its charge-plus-execute window fits before its deadline, and that feasibility test now contains \(P_{\text{harvest}}\), a quantity the device does not control and must predict.

Forecasting the next charge interval

Feasibility depends on \(P_{\text{harvest}}\) over the next few seconds to minutes, so the scheduler needs a forecast. The good news is that harvest sources are strongly autocorrelated on short horizons: indoor light, thermal gradients, and vibration change slowly relative to a charge cycle, so even a one-state predictor works well. An exponentially weighted moving average of recent charging current, \(\hat{P}_{t} = \alpha\,P_{t} + (1-\alpha)\,\hat{P}_{t-1}\), is the workhorse; slot-of-day models add a coarse daily profile for solar nodes. The forecast horizon you actually need is bounded by capacitor size: a device cannot bank more than \(\tfrac{1}{2}C(V_{\max}^2 - V_{\min}^2)\) joules, so predicting harvest further out than it takes to fill the capacitor is wasted effort. This is the estimation-under-uncertainty pattern of Chapter 4: the scheduler should carry a confidence on \(\hat{P}\) and inflate charge-time estimates conservatively when the harvest is volatile, because an optimistic forecast that misses causes a missed deadline, while a pessimistic one merely costs a little idle headroom.

Imprecise computation: trading result quality for schedulability

When the forecast says the full task set cannot meet all deadlines, the scheduler needs a graceful fallback rather than a dropped task. The imprecise-computation model supplies one: split each task into a mandatory part that must run and an optional part that improves the result if energy and time permit. This is where charging-aware scheduling reconnects to the energy-adaptive inference of Section 63.3: the mandatory part is a cheap early-exit prediction that guarantees some answer by the deadline, and the optional part is the deeper computation that sharpens it if the capacitor cooperates. The scheduler admits optional parts only when the harvest forecast leaves slack, so under a bright supply the device returns refined results and under a dim one it still returns timely coarse ones. The deadline is met by construction; only the quality floats. CARTOS-style schedulers make this the core guarantee: a bounded-quality result always arrives on time, and surplus energy is spent buying accuracy rather than idling.

import math

# Ready tasks: energy (mJ), exec time (ms), absolute deadline (ms from now),
# and whether this is the mandatory or optional part.
TASKS = [
    {"name": "classify_mandatory", "e_mj": 2.0, "c_ms": 4,  "deadline_ms": 900,  "optional": False},
    {"name": "classify_optional",  "e_mj": 6.0, "c_ms": 12, "deadline_ms": 900,  "optional": True},
    {"name": "log_background",     "e_mj": 1.0, "c_ms": 2,  "deadline_ms": 8000, "optional": True},
]

def charge_ms(e_needed_mj, e_now_mj, p_harvest_mw):
    deficit = max(0.0, e_needed_mj - e_now_mj)      # mJ still to harvest
    return math.inf if p_harvest_mw <= 0 else deficit / p_harvest_mw * 1e3  # mJ / mW -> ms

def schedule(tasks, e_now_mj, p_harvest_mw, reserve_mj=0.5):
    # Charging-aware EDF: mandatory parts first (by deadline), then optional
    # parts only if their charge+exec still fits before their deadline.
    order = sorted(tasks, key=lambda t: (t["optional"], t["deadline_ms"]))
    t_clock, e = 0.0, e_now_mj
    plan = []
    for task in order:
        need = task["e_mj"] + reserve_mj
        t_ready = t_clock + charge_ms(need, e, p_harvest_mw)      # wait to charge
        finish  = t_ready + task["c_ms"]
        if finish <= task["deadline_ms"]:
            plan.append((task["name"], round(t_ready, 1), round(finish, 1)))
            e = reserve_mj                                        # spent down to reserve
            t_clock = finish
        elif not task["optional"]:
            plan.append((task["name"], None, "MISS"))             # hard failure to flag
    return plan

for p in (2.0, 8.0):     # dim vs bright harvest
    print(f"P_harvest={p} mW ->", schedule(TASKS, e_now_mj=1.5, p_harvest_mw=p))
# P_harvest=2.0 mW -> [('classify_mandatory', 250.0, 254.0), ('log_background', 504.0, 506.0)]
# P_harvest=8.0 mW -> [('classify_mandatory', 62.5, 66.5), ('classify_optional', ...), ('log_background', ...)]

The scheduler in the listing is the reactive skeleton of CARTOS: it is charging-aware because charge_ms makes the harvest forecast a first-class term in every feasibility check, and it is imprecise-computation-aware because optional parts are admitted only against slack. A production version adds hysteresis to avoid thrashing, a persistent clock so deadlines survive a power failure mid-charge (the timekeeping problem of Chapter 3), and coordination with the checkpointing layer so a task interrupted by brown-out resumes rather than restarts. It also connects upward to the streaming-inference deadline model of Chapter 60, where the same "return a bounded-latency answer or degrade gracefully" contract governs continuously powered edge systems.

from intermittent_rt import Scheduler, task   # illustrative API

sched = Scheduler(reserve_mj=0.5, forecaster="ewma")

@task(energy_mj=2.0, deadline_ms=900, mandatory=True)
def classify(sample): ...

@task(energy_mj=6.0, deadline_ms=900, mandatory=False)   # optional refinement
def refine(sample): ...

sched.run()   # charge-aware admission, persistent deadlines, resume-on-power-loss

What's Next

In Section 63.5, we step back from any single mechanism and weigh the batteryless intelligence tradeoffs as a whole: what a device gives up in latency, accuracy, and data completeness in exchange for shedding its battery, and how the adaptation knob of 63.3 and the charging-aware schedule of this section combine into a coherent operating regime rather than two bolt-on tricks.