Main Page

AOWIS – Afritic Open Standard for Water & Agricultural Infrastructure

AOWIS (Afritic Open Water Infrastructure Standard) is an open technical standard for safe and reliable water and agricultural infrastructure, designed for low-resource environments.

It defines how systems are operated through sensors and actuators, either autonomously, manually, or in combination. AOWIS is designed to function under conditions such as unstable power, limited connectivity, and minimal technical support, supporting both online and offline operation.

Motivation

In less developed regions, such as rural areas and small towns in Africa, water distribution remains a significant challenge. While NGOs have been successfully supporting communities for decades by drilling wells, installing pumps, and sometimes building water towers, distributing water across a network on the surface is often difficult.

Local initiatives that take on these projects frequently encounter a situation where operating the system manually becomes unsustainable, requiring constant attention. Qualified personnel are scarce, and suitable technology to support automated or semi-automated operation is either unavailable under local constraints or too expensive.

This is where AOWIS aims to contribute: by providing an open standard for designing, deploying, and managing water and agricultural infrastructure in such environments. AOWIS supports both the planning phase—helping initiatives evaluate and design systems based on regional conditions such as topography—and the operational phase, including system monitoring, control, and maintenance.

In addition, AOWIS aims to support the training of local technicians and to collaborate closely with experienced NGOs and local initiatives that already operate and maintain such systems, in order to improve sustainability and reduce operational burden.

Why an Open Standard is Needed

In environments where infrastructure is built over decades by many different actors using solutions from different vendors and manufacturers, systems become fragmented, forcing operators to manage multiple incompatible tools and workflows while making daily operation, maintenance, expansion, and staff training increasingly complex and costly.

This fragmentation often results in vendor lock-in, where systems depend on specific tools, expertise, or suppliers that may not remain available over the full lifecycle of the infrastructure.

An open standard provides a shared technical foundation that enables interoperability and ensures systems can be maintained and extended independently of any single product or provider.

AOWIS defines such a foundation for water and agricultural infrastructure under real-world operational constraints.

Operation Conditions of AOWIS

AOWIS is designed to operate under the real-world conditions faced by local initiatives. These include, among others:

• unreliable power supply
• intermittent connectivity
• diverse or aging equipment
• limited availability of trained personnel
• the need for safety and autonomous operation

AOWIS enables systems that continue to function safely and reliably, even under degraded or adverse conditions.

Facing the Challenges

AOWIS addresses these operational challenges through the following principles:

• human-in-the-loop control
• offline-first operation
• safe fallback behavior
• modular and extensible logic
• shared infrastructure models
• training programs for local operators
• transparent governance

The goal is to make essential systems robust, maintainable, and locally operable.

Start Here

If you are new to AOWIS, begin with:

• Design Philosophy
• Definitions
• Normative Requirements
• Module Template
• Contributor Guide - External
• Contributor Guide - Internal
• Writing Style Guide
• AI Usage Guide
• Research Form Guide
• Naming Convention Specification
• Change Log & Versioning
• This Wiki

These pages explain how to read, use, and contribute to the standard.

List of Requirement Pages

This index lists AOWIS pages that define normative requirements (MUST/SHOULD/MAY statements) and conformance rules.

Dev Rules — specs for writing and maintaining AOWIS

• REQ-AI: AI Usage Guide

Technical Standard — system behavior and data models

• REQ-MEAS, REQ-MEAS-UI: Unit System Requirements
• REQ-MEAS-UNI: Unit Identifiers

AOWIS Documentation Structure

AOWIS documentation is organized into dedicated namespaces with clearly separated purposes.

The Standard namespace contains the normative requirements that define AOWIS compliance. The other namespaces provide the motivation, concepts, engineering knowledge, architectures, operational models, implementation guidance, reference designs, training material, and supporting information needed to understand, implement, and operate AOWIS systems.

• Motivation – Causal justification of design requirements based on real-world failures, constraints, and operational realities.
• Standard – The normative core of AOWIS. Defines requirements and definitions specifying what AOWIS-compliant systems MUST, SHOULD, or MAY do.
• Concepts – Core ideas, philosophy, rationale, and contextual understanding that explain AOWIS without prescribing a specific implementation.
• Architecture – High-level system structure, including controllers, layers, communication, data flows, and their interactions.
• Infrastructure – Physical technologies, systems, and components used in AOWIS deployments. Infrastructure pages describe classes of physical systems rather than specific implementation blueprints.
• Measurement – Definition and handling of sensor data, manual measurements, calibration, uncertainty, and derived physical values.
• Data – Data models, schemas, logging structures, synchronization formats, and data lifecycle rules.
• Operations – Runtime behavior, control logic, state transitions, fallback behavior, and decision-making during system operation.
• Modules – Reusable functional extensions that provide domain-specific capabilities within AOWIS.
• Reference – Non-normative concrete implementations, engineering blueprints, example deployments, and validated design patterns showing specific ways AOWIS systems may be built.
• Databases – Federated knowledge bases and structured supporting information used by AOWIS implementations.
• Governance – Certification, compliance, auditing, trust, licensing, versioning, and organizational governance.
• Training – Operator education, technical training, field guidance, documentation literacy, and capacity building.
• External – External projects, standards, technologies, and systems that relate to or influence AOWIS.

For a full overview, see the Table of Contents.

Roadmap

Roadmap

AOWIS has progressed beyond its initial conceptual phase. A substantial software foundation for modelling, simulating, visualizing, and eventually operating water infrastructure is under active development.

The long-term objective is a complete open-source SCADA, infrastructure modelling, simulation, and operational management platform for water and agricultural infrastructure. Planning, simulation, live monitoring, control, maintenance, and historical data should ultimately operate on the same shared infrastructure model.

EPANET currently provides the primary hydraulic and water-quality simulation engine, but AOWIS is not designed as an EPANET frontend. EPANET is one solver integrated into a broader, solver-independent AOWIS architecture.

Current Software State

The current AOWIS software stack already includes several major components:

Shared infrastructure model

The AOWIS server model provides a common representation of water infrastructure independently of a particular simulator, user interface, or field controller. Pumps, pipes, junctions, reservoirs, tanks, valves, controls, measurements, and related infrastructure can therefore be represented consistently throughout the system.

Hydraulic and water-quality simulation

A dedicated EPANET integration layer translates between the AOWIS model and EPANET and executes hydraulic and water-quality simulations. The integration supports network import and export, hydraulic behaviour, controls and rules, pumps and valves, water-quality analysis, diagnostics, simulation reports, and other EPANET functionality.

Integration of EPANET-MSX is being developed to extend this to advanced multi-species water-quality and chemical reaction modelling.

Network editor and monitoring interface

The AOWIS graphical application provides tools for creating, importing, inspecting, simulating, and visualizing water networks. This includes geographic map views, terrain-aware 3D visualization, network monitoring views, simulation configuration, and analysis of simulation results.

Geographic and terrain infrastructure

AOWIS includes mapping and terrain services for geographic placement, elevation data, basemaps, terrain visualization, and local caching. This allows hydraulic infrastructure to be evaluated together with the real terrain on which it is or may be constructed.

Local and standalone operation

AOWIS is being designed so that deployments do not depend on continuous Internet or cloud connectivity. Server, map, simulation, and user-interface components can be combined for local deployments, supporting the offline-first requirements of the project.

The software remains under active development and should not yet be considered a complete production SCADA system.

Towards a Full SCADA System

The next major development stage is to connect the existing infrastructure model and simulation environment to real infrastructure in continuous operation.

The same network that is used for planning and hydraulic simulation should eventually represent the live system:

• sensor measurements update the state of modelled infrastructure
• pumps, valves, tanks, reservoirs, wells, treatment systems, and electrical systems can be monitored in real time
• historical measurements and operational events are recorded
• operators can inspect current and historical system behaviour
• alarms and abnormal conditions are detected and presented clearly
• hydraulic and water-quality models can be compared with observed conditions
• authorized control commands can be issued to field equipment
• automation can operate within explicitly defined safety limits
• local systems continue operating safely when communication with higher-level systems is unavailable

Telemetry and Field Communication

Initial AOWIS deployments are intended to use technologies such as:

• Architecture:Protocols:LoRa/LoRaWAN for low-bandwidth long-range field communication
• Architecture:Protocols:MQTT for telemetry and message transport

The architecture should remain open to additional field and industrial protocols as required.

Future work includes:

• standardized representation of sensors, actuators, controllers, and communication endpoints
• ingestion of continuous and event-based telemetry
• manual measurements alongside automated measurements
• reliable timestamping and measurement quality information
• buffering during communication outages
• synchronization after connectivity is restored
• device health and communication-state monitoring

Monitoring, Alarms, and Historian

AOWIS is intended to develop from its current simulation and visualization capabilities into a complete operational monitoring environment.

Planned capabilities include:

• live network status
• time-series storage and visualization
• alarm and event management
• configurable alarm thresholds and priorities
• acknowledgement and audit trails
• equipment status and fault reporting
• operational dashboards
• maintenance information
• comparison of measured and simulated behaviour
• long-term analysis of water demand, pressure, flow, quality, energy use, and equipment performance

Control and Automation

AOWIS ultimately aims to support both manual and automatic control of infrastructure.

This includes:

• pumps
• valves and actuators
• storage tanks and water towers
• wells and boreholes
• treatment systems
• irrigation systems
• electrical and solar-energy infrastructure

Automation must follow the core AOWIS principles of human-in-the-loop control, safe fallback behaviour, local autonomy, and operation under degraded conditions.

Safety-critical protection should not depend solely on central software or network connectivity. Where appropriate, fundamental protections should remain implemented locally using simple and independently functioning electrical, mechanical, or controller-based systems.

Model-Assisted Operation

A major objective is to combine traditional SCADA functionality with the hydraulic and infrastructure model already present in AOWIS.

The live system may eventually use simulation and modelling to support:

• expected-versus-measured pressure and flow comparison
• leak and abnormal-consumption detection
• detection of sensor or equipment faults
• estimation of conditions at locations without sensors
• tank and reservoir management
• pump scheduling
• energy optimization
• water-quality tracking
• evaluation of proposed operator actions before execution
• demand forecasting
• planning of network expansion and infrastructure changes

This creates a path from a conventional SCADA display toward a continuously updated operational model of the physical water system.

Solver-Independent Development

Although EPANET is currently the primary hydraulic solver, hydraulic calculations and solver-specific assumptions should remain isolated from the common AOWIS infrastructure model.

This allows AOWIS to integrate additional simulators, optimization systems, agricultural models, or specialized engineering tools in the future without requiring the physical infrastructure model to be redesigned around a particular solver.

Infrastructure and Water Treatment

Development is also expanding beyond distribution networks themselves.

AOWIS should be capable of representing and supporting the planning and operation of complete water systems, including:

• wells and boreholes
• pumping stations
• reservoirs and water towers
• distribution networks
• drinking-water treatment
• desalination
• disinfection
• irrigation
• electrical and solar-energy systems

See Infrastructure for documentation of physical infrastructure technologies and Reference for concrete engineering designs and example implementations.

Hardware

Hardware development and research will continue alongside the software platform.

Priorities include:

• robust water-level, pressure, flow, and water-quality sensing
• monitoring of solar and battery systems
• locally serviceable field controllers
• pump and valve interfaces
• electrical protection
• emergency shutdown systems
• equipment suitable for heat, dust, unreliable power, and difficult logistics
• designs that can be repaired using locally available skills and components where practical

AOWIS does not require all hardware to be developed specifically for the project. Existing equipment should be integrated wherever it can satisfy the required interfaces, reliability, safety, and maintainability requirements.

Long-Term Direction

The intended result is an integrated platform covering the complete lifecycle of water infrastructure:

survey and planning → engineering and simulation → construction → commissioning → monitoring → control → maintenance → analysis → expansion

The same open infrastructure model should connect these stages instead of requiring separate, incompatible systems for engineering, SCADA, maintenance, mapping, and simulation.

AOWIS aims to make capabilities that are traditionally distributed across expensive and proprietary engineering, GIS, SCADA, telemetry, and asset-management products available through an open and interoperable platform suitable for both small local installations and larger water systems.

Governance & Legitimacy

AOWIS includes a transparent governance model to ensure:

• open participation
• clear certification processes
• stable versioning
• long‑term protection of the standard

See: Governance.

Navigation

• Table of Contents
• Glossary
• FAQ
• Change Log

• GitHub

Partners

AOWIS is an open, evolving standard. Contributions are welcome. For contact, please visit us on GitHub