This is an old revision of the document!
System Architecture Overview
This page defines the AOFS system architecture, including all layers, their responsibilities, and interactions.
It establishes authority boundaries, offline operation rules, and federation/synchronization requirements for AOFS controllers.
All AOFS-compliant systems must conform to the rules specified here.
1. Architecture Layers
AOFS defines three core layers:
Each layer has a clearly defined role, authority, and interface.
All controller layers expose a human interface appropriate to their authority and audience, while never bypassing Field Controller safety rules.
—
Field Controller Layer
See detailed page: Field Controller Layer
Purpose:
Safety-critical, authoritative irrigation control.
Requirements (normative):
Must execute irrigation schedules locally.
Must read and enforce all sensor data (soil moisture, tank levels, rain, battery status).
Must enforce fail-safe rules: prevent flooding, over-irrigation, pump damage.
Must operate fully offline, without network connectivity.
Must never accept remote commands that bypass safety logic.
Must log all irrigation events and safety-triggered actions for audit purposes.
Must provide an embedded UI for on-site operators to monitor and override only non-critical functions.
Examples of Field Controller hardware: ESP32, Arduino-compatible embedded controllers.
—
Farm Controller Layer (Local / Federated)
See detailed page: Farm Controller Layer (Local / Federated)
Purpose:
Supervisory and management layer on-site; provides local operator interface and federation.
Requirements (normative):
Must provide a full UI for field operators to monitor and configure the farm.
Must operate fully offline with authoritative access to local data.
Must aggregate telemetry from Field Controllers.
Must support peer-to-peer federation with other Farm Controllers or HQ Controllers.
Must enforce the rule that Field Controllers remain authoritative for all safety-critical actions.
Must support pull/push synchronization of configuration, logs, and firmware updates.
Must provide conflict resolution mechanisms for configurations (e.g., timestamp-based, operator approval).
Must allow operators to trigger manual requests or schedule changes, validated against Field Controller safety rules.
Behavioral Rules:
Offline operation: farm continues irrigation and monitoring normally if internet is unavailable.
Sync: data and configuration propagate when connectivity is restored.
Logging: all operator actions, sync events, and configuration changes must be logged.
Examples of Farm Controller hardware: NanoPi, Raspberry Pi, other industrial-grade single-board computers.
—
HQ / Federated Controller Layer
See detailed page: HQ / Federated Controller Layer
Purpose:
Global oversight, analytics, and management of multiple farms.
Requirements (normative):
Must receive telemetry and logs from multiple Farm Controllers.
Must provide reporting, dashboards, and aggregated analytics.
Must support configuration distribution to Farm Controllers when authorized.
Must never override Field Controller safety rules.
Must maintain full audit trails of all data exchanges and actions.
Must provide interfaces for managers to monitor multiple farms, analyze data, and submit authorized configuration changes.
Behavioral Rules:
HQ controller may act as a “central” sync point, but the architecture remains decentralized.
Federation: HQ may push configuration updates or pull logs, but offline farms continue autonomous operation.
—
2. Authority and Safety Rules
1. Field Controller Authority:
2. Supervisory Controller Rule:
3. Offline Operation:
4. Federation / Sync Rule:
5. Auditability:
All layers must log events, configuration changes, and synchronization actions.
Logs must be preserved locally and transmitted to upstream controllers when possible.
—
3. Layer Interaction Summary
| Layer | Primary Role | Connectivity Requirement | Authority | Human Interface |
| ——- | ————- | ————————- | ———- | —————- |
| Field Controller | Execute irrigation & safety | None (offline) | Authoritative locally | Embedded UI for monitoring and non-critical overrides |
| Farm Controller | Local supervision & peer sync | Optional (for federation) | Supervisory | Full UI for monitoring, configuration, and local operator control (validated by Field Controller) |
| HQ Controller | Global oversight & analytics | Required for federation | Supervisory | Dashboards and reporting for managers; may submit authorized configuration updates |
—
4. Compliance Notes
- Any AOFS-compliant deployment must implement all three layers as defined, though multiple roles may be co-located on the same hardware.
- Federated operations must preserve local authority.
- All human interface interactions must respect Field Controller safety rules.
- Failure to respect authority boundaries invalidates AOFS compliance.