Problem statement
Design the object model and scheduling APIs for a multi-zone irrigation controller that waters a garden through a set of solenoid valves on programmed schedules.
Operating context. One controller drives 4 to 16 watering zones, each an independently openable valve. The user defines programs (for example, 'lawn program: zones 1-3, start 5:30am, Mon/Wed/Fri, 12 minutes each'). Because the shared water supply cannot feed every zone at once, zones in a program run sequentially, one open at a time. A rain sensor or a manual 'rain delay' can suspend watering; a seasonal 'water budget' percentage scales every run's duration. The user can also manually run a single zone now. Everything runs in-process on the device.
Out of scope. Cloud weather-forecast integration, the mobile app and its endpoints, flow-meter leak detection hardware, pump-start relay wiring, and multi-controller mesh coordination across a property.
What to produce. The class hierarchy (controller, zone, valve, program, run queue, scheduler), the public API each class exposes, and the state transitions for a valve and for a running program. Be explicit about: how the controller guarantees at most one valve open at a time, how rain-delay and water-budget rules are applied without rewriting the run logic, and how the schedule-selection policy is pluggable (fixed calendar today, sensor-driven tomorrow).
Functional requirements
- Let the user create, edit, and query watering programs, each binding an ordered set of zones to a start time, day pattern, and per-zone duration.
- Execute a due program by running its zones sequentially, opening exactly one valve at a time for the scaled duration.
- Apply a rain delay or active rain sensor by suspending scheduled runs until the delay clears, without deleting the program.
- Scale every run's duration by the current seasonal water-budget percentage before the valve opens.
- Allow an immediate manual run of a single zone, safely preempting or queueing behind any scheduled run.
- Report status: which zone (if any) is open, seconds remaining, and the next scheduled program start.
Non-functional requirements
- The single-valve invariant holds under concurrent triggers: a manual run and a scheduled run can never open two valves at once.
- Selecting the next due program is at most O(log N) in the number of programs; per-tick evaluation is O(1).
- The schedule-selection policy is pluggable so a sensor-driven or forecast-driven strategy replaces the calendar one without touching valve control.
- The valve state machine is thread-safe and always leaves hardware in a safe (closed) state on abort or fault.
- The design is unit-testable without real valves or wall-clock time, with clock, sensor, and valve driver injected.
- Adding a new zone or a new suspension source (freeze sensor) is a localised change behind existing interfaces.
Topics
- System Design LLD
- Oop Solid
- Patterns Strategy
- Concurrency Mutual-Exclusion
- Iot Actuator