Main Page: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| Line 112: | Line 112: | ||
{{Header box | {{Header box | ||
| title = | | title = AOWIS Documentation Structure | ||
| color = purple | | color = purple | ||
| body = | | body = | ||
AOWIS documentation is organized into dedicated namespaces with clearly separated purposes. | |||
The [[Standard:Main_Page|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. | |||
For a full overview, see the | * [[Motivation:Main_Page|Motivation]] – Causal justification of design requirements based on real-world failures, constraints, and operational realities. | ||
* [[Standard:Main_Page|Standard]] – The normative core of AOWIS. Defines requirements and definitions specifying what AOWIS-compliant systems MUST, SHOULD, or MAY do. | |||
* [[Concepts:Main_Page|Concepts]] – Core ideas, philosophy, rationale, and contextual understanding that explain AOWIS without prescribing a specific implementation. | |||
* [[Architecture:Main_Page|Architecture]] – High-level system structure, including controllers, layers, communication, data flows, and their interactions. | |||
* [[Infrastructure:Main_Page|Infrastructure]] – Physical technologies, systems, and components used in AOWIS deployments. Infrastructure pages describe classes of physical systems rather than specific implementation blueprints. | |||
* [[Measurement:Main_Page|Measurement]] – Definition and handling of sensor data, manual measurements, calibration, uncertainty, and derived physical values. | |||
* [[Data:Main_Page|Data]] – Data models, schemas, logging structures, synchronization formats, and data lifecycle rules. | |||
* [[Operations:Main_Page|Operations]] – Runtime behavior, control logic, state transitions, fallback behavior, and decision-making during system operation. | |||
* [[Modules:Main_Page|Modules]] – Reusable functional extensions that provide domain-specific capabilities within AOWIS. | |||
* [[Reference:Main_Page|Reference]] – Non-normative concrete implementations, engineering blueprints, example deployments, and validated design patterns showing specific ways AOWIS systems may be built. | |||
* [[Databases:Main_Page|Databases]] – Federated knowledge bases and structured supporting information used by AOWIS implementations. | |||
* [[Governance:Main_Page|Governance]] – Certification, compliance, auditing, trust, licensing, versioning, and organizational governance. | |||
* [[Training:Main_Page|Training]] – Operator education, technical training, field guidance, documentation literacy, and capacity building. | |||
* [[External:Main_Page|External]] – External projects, standards, technologies, and systems that relate to or influence AOWIS. | |||
For a full overview, see the [[AOWIS:Table_of_Contents|Table of Contents]]. | |||
}} | }} | ||
Revision as of 14:28, 5 September 2026

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.

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.

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.
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.
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.
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 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.

At this stage, AOWIS is in an early development and conceptualization phase. The following areas outline the current technical priorities:
Research
- Decide which Wireless Protocols could or should be used for AOWIS.
Hardware
- Develop sensors for measuring water levels in reservoirs.
- Develop voltage monitoring to support sizing and management of solar battery systems.
- Design mechanisms for emergency shutdown of electrical systems within milliseconds in case of overvoltage or critical faults.
- This should be done low-tech with regular electrician solutions.
Software
- Begin conceptualization of the core controller.
- The controller must be capable of modeling and evaluating complex graphs representing water distribution networks in real time, enabling dynamic adaptation to changing conditions.
AOWIS includes a transparent governance model to ensure:
- open participation
- clear certification processes
- stable versioning
- long‑term protection of the standard
See: Governance.
AOWIS is an open, evolving standard. Contributions are welcome. For contact, please visit us on GitHub

