Skip to content
Technology 06 · Digital Twin Simulator

Test the RiceGuard data pipeline without physical field hardware.

The simulator sends realistic artificial field readings through the RiceGuard software. It is an engineering and demonstration environment, not the live production dashboard.

Simulator · local engineering environment

Four nodes. One complete test chain.

N01 N02 N03 N04 GW

Simulator model · not an exact representation of Generation 4 hardware

38 / 38 Tasks complete
137 / 137 Automated tests passing
84% Code coverage
5 / 5 Development phases complete
What the digital twin is for

Test system behaviour before field deployment.

It reproduces the software chain in a controlled environment. It does not replace testing with real hardware in a real field.

  1. 01 Reproduce

    Generate realistic field readings across four simulated nodes.

  2. 02 Process

    Run readings through validation, anomaly and priority logic.

  3. 03 Stress

    Trigger weather, power, connection and node failures safely.

  4. 04 Observe

    Inspect readings, alerts, recovery and system state.

A complete simulated field

Four nodes reproduce a full day of field behaviour.

Each node produces eleven readings with daily cycles, realistic variation and slower responses deeper in the soil.

Simulated topology Sensor nodes → LoRa → Gateway
N01 N02 N03 N04 GW
04 Nodes
11 Readings / node
24h Daily model
Eleven readings per node
  1. Atmosphere

    Air temperature · humidity · light

  2. Soil moisture

    5 cm · 15 cm · 30 cm

  3. Soil condition

    pH · temperature at three depths

  4. Power

    Battery state of charge

Modelled behaviour Daily cycles · rolling noise · depth-dependent delays

Six-stage gateway pipeline

How a flood reading becomes a qualified system event.

The simulator exposes each decision from sensing to transmission, including what happens when a packet cannot be sent.

  1. 01 Sense

    Moisture rises

  2. 02 Validate

    Range + outlier checks

  3. 03 Summarise

    5m · 15m · 1h windows

  4. 04 Interpret

    Threshold + rate of change

  5. 05 Prioritise

    Critical event becomes P1

  6. 06 Transmit

    Power + connection gate

If transmission is blocked, the packet is buffered and retried.

LoRa, connectivity and energy

Connection and battery state change system behaviour.

LoRa carries readings from simulated nodes to the gateway. Power and backhaul availability then determine when and how data is sent onward.

Connectivity model

Three simulated communication paths

PathWhen usedPower / payloadBehaviour
4G Primary path Highest routine power Normal transmission
NB-IoT Cellular unavailable Lower power · smaller payload Compressed transfer
Satellite Final fallback Smallest payload P1 critical only
Power model

80 W solar · 25 Ah / 12 V LiFePO4 · 300 Wh

ChargeModeIntervalPriorityPreferred path
>80% Normal 5 min P1–P4 4G
50–80% Reduced 15 min P1–P4 Prefer NB-IoT
30–50% Low 30 min P1 + P2 NB-IoT
<30% Critical 60 min P1 only NB-IoT

Model boundary This is an earlier simulator specification, not an exact digital copy of the Generation 4 station.

Five adverse scenarios

Trigger a condition. Observe the response.

ScenarioModelled changeDurationRecoveryWhat to observe
Flood Moisture moves toward 100 %RH 2 h 48 h Filter → anomaly → P1 transport
Drought Moisture moves toward 10% 72 h 24 h Threshold and recovery curve
Storm Cloud increases; signal degrades 6 h 2 h Power loss and radio fallback
Pest pH + moisture anomalies on 2 nodes 24 h 12 h Cross-node evidence
Node failure One node goes offline 12 h Immediate Health state and missing data

These scenarios test system behaviour, not field prediction accuracy.

Real-time simulator dashboard

One engineering interface shows the whole test chain.

This local simulator interface is separate from the live Farmer and Phenology dashboards.

Simulator dashboard · local engineering environment
Simulator dashboard Replace with the supplied simulator capture before launch
What the screen shows
  1. Field map
  2. Readings + alerts
  3. Power + connectivity
  4. Diagnostics
  5. Scenario controls
Control and evidence

A documented REST API controls the simulator.

  1. Observe 6 GET endpoints

    Status · nodes · alerts · power · connectivity · diagnostics

  2. Trigger 2 scenario endpoints

    Start a named adverse condition · clear the active scenario

  3. Control 2 clock endpoints

    Set 1×, 10× or 60× speed · pause or resume

137 automated tests by system area Numbers show test counts
  1. Clock 13
  2. Models 10
  3. Sensors 18
  4. Gateway 12
  5. Connectivity 19
  6. Power 20
  7. Scenarios 24
  8. Web 14
  9. Integration 7
Known limitations

What the simulator does not prove.

It verifies software-pipeline behaviour. It does not replace field validation or represent the deployed Generation 4 architecture exactly.

  1. 01
    Coverage gaps

    MQTT and gateway-storage test coverage are 45%; additional edge cases remain to be tested.

  2. 02
    Simplified recovery

    Flood and drought recovery curves are test models, not agronomic forecasts.

  3. 03
    Local access only

    The dashboard and API have no TLS or authentication and are not for public access.

  4. 04
    Single Python process

    The simulator structure is not the deployed gateway architecture.

Next · Research & Knowledge

The simulator tests the pipeline. The field tests the system.

Continue to Field Trial for the real installation, seasonal test plan, study design and documented evidence.

View the system in the field