Standard:Main Page

The AOWIS Standard is the normative core of the Afritic Open Water Infrastructure Standard.

It defines requirements for interoperable, safe, maintainable, and extensible systems for water and irrigation infrastructure, including software, data, measurements, communication, monitoring, control, automation, and operational behaviour.

AOWIS is intended to be applicable to both small community installations and larger professional systems. At the same time, the standard is designed so that compliant systems can remain practical under difficult conditions such as intermittent connectivity, unreliable power, limited technical resources, and the need for local autonomous operation.

Purpose of the Standard

The purpose of the AOWIS Standard is to define a common technical foundation that allows independently developed systems and components to work together without requiring dependence on a particular vendor, product, software implementation, communication technology, or engineering tool.

The standard defines what an AOWIS-compliant system is required or expected to do. It does not generally prescribe one specific implementation where different implementations can satisfy the same requirements.

Supporting AOWIS documentation explains the engineering principles, infrastructure, architectures, reference designs, operational practices, and reasoning behind these requirements.

Normative Language

Normative requirements use the terms:

MUST / MUST NOT

A mandatory requirement for conformance wherever the requirement applies.

SHOULD / SHOULD NOT

A recommended requirement. A valid reason may exist to deviate from it, but the consequences of doing so should be understood and considered.

MAY

An optional capability, behaviour, or implementation choice.

Normative requirements are assigned identifiers such as REQ-MEAS so that they can be referenced unambiguously from specifications, implementations, tests, and compliance documentation.

See Normative Requirements for the rules governing normative language and requirement identifiers.

Definitions

Terms with a specific meaning within AOWIS are defined in:

• Definitions

Where a term has an AOWIS-specific normative definition, that definition takes precedence when interpreting AOWIS requirements.

Requirement Index

This section provides an index of currently defined AOWIS requirements.

The standard is under active development. The list will grow as additional areas are specified.

Technical Requirements

Requirement ID	Subject	Specification
REQ-MEAS	Measurement and unit requirements	Unit System Requirements
REQ-MEAS-UI	Presentation and user-interface handling of units	Unit System Requirements
REQ-MEAS-UNI	Canonical units	Canonical Units

AOWIS Development Requirements

Some normative requirements govern development and maintenance of the AOWIS project itself rather than technical implementations of AOWIS systems.

Requirement ID	Subject	Specification
REQ-AI	Use of artificial intelligence in AOWIS development and documentation	AI Usage Guide

These development requirements do not automatically constitute requirements for an AOWIS-compliant water infrastructure system.

Location of Normative Requirements

The Standard namespace provides the normative core and common definitions of AOWIS.

Domain-specific normative requirements may also be defined within the documentation for the relevant technical domain. Such requirements are normative only when they are explicitly identified as AOWIS requirements.

For example, measurement requirements are maintained within the Measurement documentation because their meaning depends directly on the measurement and unit model.

This allows requirements to remain close to the technical material they govern while still being indexed centrally here.

Conformance

A system, component, implementation, or deployment claiming AOWIS conformance is expected to satisfy all applicable MUST and MUST NOT requirements of the AOWIS version against which conformance is claimed.

SHOULD and SHOULD NOT requirements describe the recommended AOWIS design. Where such a recommendation is not followed, the reason and consequences should be understood and, where appropriate, documented.

MAY requirements describe optional capabilities and do not require implementation unless another applicable requirement makes them necessary.

Not every requirement applies to every AOWIS implementation. Applicability depends on the infrastructure, functions, modules, interfaces, and capabilities implemented by the system.

Requirements relating to certification, auditing, compliance claims, and governance are documented under Governance.

Scope

AOWIS is intended to provide a common technical foundation across the lifecycle of water and irrigation infrastructure.

Areas covered or intended to be covered by the standard include:

• infrastructure modelling
• planning and engineering
• measurements and instrumentation
• monitoring and SCADA
• control and automation
• telemetry and communication
• data representation and exchange
• offline and distributed operation
• hydraulic modelling
• water-quality modelling
• wells and boreholes
• pumping systems
• reservoirs, tanks, and water towers
• water distribution networks
• treatment and disinfection
• desalination
• irrigation systems
• electrical and energy infrastructure associated with water systems
• alarms, events, and historical operational data
• maintenance and operational workflows

AOWIS does not require all of these capabilities to be present in every implementation.

It also does not require a particular manufacturer, commercial product, hydraulic solver, communication protocol, database, operating system, or software implementation unless a specific normative requirement explicitly states otherwise.

Relationship to Other AOWIS Documentation

The standard is supported by several documentation namespaces with different purposes:

• Motivation — real-world problems, failures, constraints, and operational realities that motivate requirements
• Concepts — principles, rationale, and conceptual understanding
• Architecture — system structure, communication, layers, components, and data flows
• Infrastructure — physical infrastructure, equipment, and technologies
• Measurement — measurements, units, calibration, uncertainty, and physical values
• Data — data models, schemas, synchronization, logging, and data lifecycle
• Operations — runtime behaviour, control logic, fallback behaviour, and operational decision-making
• Modules — reusable functional extensions and domain-specific capabilities
• Reference — concrete implementations, engineering designs, examples, and validated patterns
• Databases — structured supporting knowledge and federated databases
• Governance — compliance, certification, auditing, versioning, licensing, and governance
• Training — operator education, technical training, and field guidance
• External — external standards, projects, technologies, and systems relevant to AOWIS

These supporting namespaces may explain why a requirement exists or how it can be implemented without making a particular implementation mandatory.

For a broader overview of the documentation, see the AOWIS Table of Contents.

Design Principles

Normative requirements should be consistent with the broader AOWIS design philosophy, including:

• interoperability
• open interfaces
• modularity
• local autonomy
• offline-first operation where practical
• safe fallback behaviour
• human-in-the-loop control
• maintainability
• long service life
• avoidance of unnecessary vendor lock-in
• operation under degraded conditions
• use of existing compatible equipment and standards where appropriate

See Design Philosophy for the broader rationale behind these principles.

Versions and Changes

AOWIS is an evolving standard.

Normative requirements may be extended, clarified, deprecated, or changed as the standard develops. Changes that affect conformance must therefore be identifiable and traceable.

See:

• Change Log & Versioning
• Governance
• Naming Convention Specification

Contributing to the Standard

Contributions to AOWIS are welcome.

Normative requirements should address identifiable technical, operational, safety, interoperability, maintainability, or lifecycle needs rather than arbitrary implementation preferences.

Before proposing or modifying normative requirements, contributors should consult:

• Design Philosophy
• Contributor Guide — External
• Contributor Guide — Internal
• Writing Style Guide
• Normative Requirements

Software implementation, source-code issues, and pull requests are handled through GitHub.

Broader discussion and participation take place through the AOWIS community channels described on the main page.

See Also

• Definitions
• Normative Requirements
• Design Philosophy
• Table of Contents
• Governance
• Glossary