Afritic Open Farming Standard

User Tools

Site Tools

You are here: Afritic Open Water and Farming Standard (AOWFS) » System Architecture Overview
Trace: • AOFS Change Log & Versioning • Valves, Pumps & Actuation • Water Towers • System Architecture Overview • Farm Controller Layer (Local / Federated)
architecture:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
architecture:start [2026/01/21 20:27] – bsamuelarchitecture:start [2026/02/23 01:11] (current) – [8. References] bsamuel
Line 1: Line 1:
 ====== System Architecture Overview ====== ====== System Architecture Overview ======
  
-This page defines the **AOFS system architecture**, including all layers, their responsibilities, and interactions.  +This page defines the **AOFS system architecture**, including all layers, their responsibilities, interactions, and data flows.  
 It establishes **authority boundaries**, **offline operation rules**, and **federation/synchronization requirements** for AOFS controllers. It establishes **authority boundaries**, **offline operation rules**, and **federation/synchronization requirements** for AOFS controllers.
  
Line 14: Line 14:
   * [[architecture:hq_controller:start|HQ / Federated Controller Layer]]   * [[architecture:hq_controller:start|HQ / Federated Controller Layer]]
  
-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**. All controller layers **expose a human interface appropriate to their authority and audience**, while **never bypassing Field Controller safety rules**.
  
 --- ---
  
-==== Field Controller Layer ==== +===== 2. Authority & Data Flow Diagram =====
-See detailed page: [[architecture:field_controller:start|Field Controller Layer]]+
  
-**Purpose:**   +<code> 
-Safety-critical, authoritative irrigation control.+                ┌───────────────────────┐ 
 +                │   HQ / Federated      │ 
 +                │      Controller       │ 
 +                │  Dashboards & Reports │ 
 +                └─────────┬─────────────┘ 
 +                          │ Push/Pull Config & Logs 
 +                          ▼ 
 +                ┌───────────────────────┐ 
 +                │  Farm Controller      │ 
 +                │  Local UI & Monitoring│ 
 +                │  Federation & Sync    │ 
 +                └─────────┬─────────────┘ 
 +                          │ Telemetry & Commands 
 +                          ▼ 
 +                ┌───────────────────────┐ 
 +                │  Field Controller     │ 
 +                │  Autonomous Safety    │ 
 +                │  Irrigation Control   │ 
 +                │  Sensor Monitoring    │ 
 +                └───────────────────────┘ 
 +</code>
  
-**Requirements (normative):** +**Legend:**
-  * 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.+  * **Field Controller:** authoritative for safety-critical irrigation.   
 +  * **Farm Controller:** local supervision, configuration, and federation; respects Field Controller authority.   
 +  * **HQ Controller:** multi-farm oversight, reporting, analytics; may propose updates but cannot override Field Controller safety logic.  
  
 --- ---
  
-==== Farm Controller Layer (Local / Federated) ==== +===== 3. Controller Responsibilities =====
-See detailed page: [[architecture:farm_controller:start|Farm Controller Layer (Local / Federated)]]+
  
-**Purpose:**   +| Layer | Primary Role | Human Interface | Connectivity | Authority | 
-Supervisory and management layer on-site; provides local operator interface and federation.+|-------|-------------|----------------|-------------|----------| 
 +| Field Controller | Execute irrigation & safety | Embedded UI for monitoring / non-critical overrides | None (offline) | Authoritative locally | 
 +| Farm Controller | Local supervision & federation | Full UI: monitoring, configuration | Optional (for federation) | Supervisory (non-critical only) | 
 +| HQ Controller | Multi-farm oversight & analytics | Dashboards, reporting, config proposals | Required for federation | Supervisory (proposals only) |
  
-**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:** +===== 4. Federation / Sync Model =====
-  * 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.+  * **Push/Pull:** Farm Controllers sync with HQ and/or peer farms.   
 +  * **Conflict Resolution:**   
 +    * Timestamp precedence   
 +    * Operator approval for schedule/config conflicts   
 +    * Field Controller safety rules **always take priority**   
 +  * **Offline First:**   
 +    * Controllers continue autonomous operation if disconnected   
 +    * Logs and changes queue for synchronization once connectivity is restored  
  
 --- ---
  
-==== HQ / Federated Controller Layer ==== +===== 5. Human Interface Rules =====
-See detailed page: [[architecture:hq_controller:start|HQ / Federated Controller Layer]]+
  
-**Purpose:**   +  * All controllers expose interfaces appropriate to their role:   
-Global oversight, analytics, and management of multiple farms. +    * Field Controller: embedded status UI, safety alerts, non-critical operator overrides   
- +    * Farm Controller: full local UI for monitoring, configuration, and federation   
-**Requirements (normative):** +    * HQ Controller: multi-farm dashboards, analytics, authorized configuration proposals   
-  * Must receive telemetry and logs from multiple Farm Controllers. +  * No interface may bypass Field Controller safety rules.  
-  * 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 =====+===== 6. Communication Model & Protocol Independence =====
  
-1. **Field Controller Authority:**   +  * Controller layers may communicate using one or more standardized protocols (see [[architecture:protocols:start|Communication Protocols & Standards]]) 
-   * Field Controller decisions are **authoritative** and cannot be overridden remotely.+  * Protocol choice does not define authority 
 +  * Communication transport is strictly separated from control authority
  
-2. **Supervisory Controller Rule:**   +  * Field Controller authority is defined by architectural rules, not by message origin 
-   * Farm and HQ Controllers may propose changes, but **Field Controller safety rules cannot be bypassed**.+  * Remote commands received via MQTT, AMQP, or other protocols must always be validated locally 
 +  * Loss of connectivity must never affect safety-critical irrigation execution 
 +  * Communication failure must default to safe autonomous operation
  
-3. **Offline Operation:**   +  * AOFS architecture is protocol-agnostic 
-   * Any controller layer on-site must maintain **full operational capability** without connectivity. +  * Multiple protocols may coexist within a deployment 
- +  * Implementations must ensure auditability of all received and transmitted messages
-4. **Federation / Sync Rule:**   +
-   * Controllers may act as peers in a push/pull sync network. +
-   * Conflict resolution must be deterministic and logged. +
- +
-5. **Auditability:**   +
-   * All layers must log events, configuration changes, and synchronization actions. +
-   * Logs must be preserved locally and transmitted to upstream controllers when possible.+
  
 --- ---
 +===== 7. Compliance Notes =====
  
-===== 3. Layer Interaction Summary ===== +  * AOFS-compliant deployments **must implement all three layers** as defined.   
- +  * Field Controller safety rules **cannot be overridden** by higher layers.   
-| Layer | Primary Role | Connectivity Requirement | Authority | Human Interface | +  * All push/pull, configuration changes, and operator actions **must be logged**.   
-|-------|-------------|-------------------------|----------|----------------| +  * Offline operation **must not compromise irrigation or safety**.   
-| Field Controller | Execute irrigation & safety | None (offline) | Authoritative locally | Embedded UI for monitoring and non-critical overrides | +  * Failure to respect authority boundaries **invalidates AOFS compliance**.
-| 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 =====+===== 8. References =====
  
-- Any AOFS-compliant deployment **must implement all three layers** as defined, though multiple roles may be co-located on the same hardware. +  * [[architecture:field_controller:start|Field Controller Layer]]   
-- Federated operations **must preserve local authority**. +  * [[architecture:farm_controller:start|Farm Controller Layer (Local / Federated)]]   
-- All human interface interactions **must respect Field Controller safety rules**. +  * [[architecture:hq_controller:start|HQ / Federated Controller Layer]]   
-- Failure to respect authority boundaries **invalidates AOFS compliance**.+  * [[hydraulics:start]]   
 +  * [[electrical|Electrical & Control Interfaces]]   
 +  * [[sensors|Measuring, Monitoring & Documentation Systems]]  
  
architecture/start.1769027256.txt.gz · Last modified: by bsamuel

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki