Afritic Open Farming Standard

User Tools

Site Tools

You are here: Afritic Open Water and Farming Standard (AOWFS) » System Architecture Overview
Trace: • Farm Controller Layer (Local / Federated) • HQ / Federated Controller Layer • Electrical & Power Control Interfaces • Water Towers
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:15] – 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 8: Line 8:
 ===== 1. Architecture Layers ===== ===== 1. Architecture Layers =====
  
-AOFS defines four core layers:+AOFS defines three core layers:
  
-  - **Field Controller Layer**   +  * [[architecture:field_controller:start|Field Controller Layer]] 
-  - **Farm Controller Layer (Local / Federated)**   +  * [[architecture:farm_controller:start|Farm Controller Layer (Local / Federated)]] 
-  - **HQ / Federated Controller Layer**   +  * [[architecture:hq_controller:start|HQ / Federated Controller Layer]]
-  - **Human Interaction 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**.
  
 --- ---
  
-==== 1.1 Field Controller Layer ====+===== 2. Authority & Data Flow Diagram =====
  
-**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.+
  
-**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.  
  
 --- ---
  
-==== 1.2 Farm Controller Layer (Local / Federated) ====+===== 3. Controller Responsibilities =====
  
-**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 | 
-**Requirements (normative):** +| Farm Controller | Local supervision & federation | Full UI: monitoring, configuration | Optional (for federation) | Supervisory (non-critical only) | 
-  * Must provide a full UI for field operators to monitor and configure the farm. +| HQ Controller | Multi-farm oversight & analytics | Dashboards, reporting, config proposals | Required for federation | Supervisory (proposals only) |
-  * 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). +
- +
-**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.+
  
 --- ---
  
-==== 1.3 HQ / Federated Controller Layer ====+===== 4. Federation / Sync Model =====
  
-**Purpose:**   +  * **Push/Pull:** Farm Controllers sync with HQ and/or peer farms.   
-Global oversight, analytics, and management of multiple farms. +  * **Conflict Resolution:**   
- +    * Timestamp precedence   
-**Requirements (normative):** +    * Operator approval for schedule/config conflicts   
-  * Must receive telemetry and logs from multiple Farm Controllers. +    * Field Controller safety rules **always take priority**   
-  * Must provide reporting, dashboards, and aggregated analytics. +  * **Offline First:**   
-  * Must support configuration distribution to Farm Controllers when authorized. +    * Controllers continue autonomous operation if disconnected   
-  * Must **never override Field Controller safety rules**. +    * Logs and changes queue for synchronization once connectivity is restored  
-  * Must maintain full audit trails of all data exchanges and actions. +
- +
-**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.+
  
 --- ---
  
-==== 1.4 Human Interaction Layer ====+===== 5. Human Interface Rules =====
  
-**Purpose:**   +  * All controllers expose interfaces appropriate to their role:   
-Interface for humans to supervise, monitor, and optionally configure the system. +    * 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 allow operators to monitor farm status, irrigation events, and alerts. +  * No interface may bypass Field Controller safety rules.  
-  * Must allow operators to submit configuration changes, schedules, or manual requests. +
-  * Must validate all requests against **Field Controller rules** before execution. +
-  * Must integrate with Farm and HQ controllers as necessary, respecting authority boundaries.+
  
 --- ---
  
-===== 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 | +  * 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 | +  * Failure to respect authority boundaries **invalidates AOFS compliance**.
-| Farm Controller | Local supervision & peer sync | Optional (for federation) | Supervisory | +
-| HQ Controller | Global oversight & analytics | Required for federation | Supervisory | +
-| Human Interface | Operator monitoring & configuration | Optional | Supervisory |+
  
 --- ---
  
-===== 4. Compliance Notes ===== +===== 8. References =====
- +
-- Any AOFS-compliant deployment **must implement all four layers** as defined, though multiple roles may be co-located on the same hardware. +
-- Federated operations **must preserve local authority**. +
-- Failure to respect authority boundaries **invalidates AOFS compliance**.+
  
 +  * [[architecture:field_controller:start|Field Controller Layer]]  
 +  * [[architecture:farm_controller:start|Farm Controller Layer (Local / Federated)]]  
 +  * [[architecture:hq_controller:start|HQ / Federated Controller Layer]]  
 +  * [[hydraulics:start]]  
 +  * [[electrical|Electrical & Control Interfaces]]  
 +  * [[sensors|Measuring, Monitoring & Documentation Systems]]  
  
architecture/start.1769026552.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