Here is a compact English SRD version that integrates everything we have shaped so far, in a form you can hand to investors, defense evaluators, or R&D teams.
SYSTEM REQUIREMENTS DOCUMENT (SRD)
Project Name: HIVE SCOUT (KOVAN İZCİ) v2.0
System Class: Industrial / Defense-Grade Atmospheric Sensor Network
Document Status: Frozen Baseline Architecture
1.0 SCOPE AND OPERATIONAL OBJECTIVES
1.1 System Definition
HIVE SCOUT is an autonomous, fault‑tolerant, networked atmospheric analysis system designed to detect biological/chemical aerosol risk clustering in urban street canyons and stagnant air conditions.
The system uses a tracer gas (Isobutylene) and high‑grade environmental sensing to identify physical “air traps” where aerosols can accumulate.
1.2 Out‑of‑Scope Functions
The system does not directly detect viruses, bacteria, or specific DNA/RNA signatures.
Instead, it measures the potential for particles to remain suspended in air using statistical and fluid‑dynamics‑based vector analysis to map “risk regions”.
1.3 Operational Environment
Field nodes shall operate outdoors under:
- Temperature range: −20 °C to +50 °C
- Relative humidity range: 0% to 100% (including condensation)
- Severe meteorological conditions (rain, fog, exhaust plumes)
Enclosures shall be designed to at least IP67 ingress‑protection level.
2.0 HARDWARE AND SENSOR SPECIFICATIONS
2.1 Core Processing Unit
Each field node shall use a microcontroller with:
- ARM Cortex‑M4 (or equivalent) core
- Hardware floating‑point unit (FPU)
- Sufficient RAM/Flash to execute floating‑point sensor equations and state machine logic in millisecond‑scale cycles.
2.2 Sensor Tolerance and Calibration Matrix
Minimum performance requirements:
| Sensor Type | Target Quantity | Limit of Detection (LOD) | Max Error | Critical Environmental Blind Point |
|---|---|---|---|---|
| PID (10.6 eV lamp) | Isobutylene (C₄H₈) | 1 ppb | ±2% | ≥ 95% RH (condensation on UV optics) |
| Dual‑channel NDIR | CO₂ (human breath) | 400 ppm | ±15 ppm | Outside −20 °C / +50 °C range |
| Capacitive polymer RH | Relative humidity (RH) | 0% RH | ±1.0% RH | Direct condensation on sensor surface |
| Ultrasonic anemometer | Wind vector $$\vec{v}$$ | 0.01 m/s | ±2% | Heavy rain (ultrasonic signal disruption) |
Each sensor shall be factory‑ or lab‑calibrated; calibration intervals and drift limits shall be specified in the detailed hardware annex.
2.3 Mechanical and Active Purge Design
Passive air intake is not acceptable.
Each device shall include:
- A controlled‑flow air path pulling ambient air into the sensor chamber at a defined flow rate.
- A micro‑compressor or turbine fan capable of reversing flow and actively purging the chamber under saturation conditions (dust, exhaust, condensation).
3.0 MATHEMATICAL COMPENSATION ALGORITHMS
Raw sensor data shall be compensated at node level before transmission to the cloud. The following functions are mandatory.
3.1 PID Sensor Humidity Quenching Compensation
3.1.1 Purpose
To mitigate the impact of high relative humidity (RH) on UV energy absorption and condensation‑induced leakage in PID outputs, ensuring accurate Isobutylene readings.
3.1.2 Calibration Requirements
For each PID module (per device):
- Calibrate at a fixed Isobutylene concentration $$C_{ref}$$ (e.g. 100 ppb) and multiple RH points:
$$RH \in {30\%, 60\%, 90\%}$$. - At each $$RH_i$$, measure PID raw output $$C_{raw}(RH_i)$$ and derive a humidity quenching factor:
$$
\alpha(RH_i) = \frac{C_{raw}(RH_i)}{C_{raw}(RH_{ref})}
$$
where $$RH_{ref}$$ is a low‑humidity reference (e.g. 30% RH).
This yields a per‑sensor $$\alpha(RH)$$ curve stored in non‑volatile memory.
3.1.3 On‑Node Compensation Function
For each acquisition cycle, the node shall:
- Read raw PID concentration: $$C_{raw}$$
- Read instantaneous relative humidity: $$RH_{meas}$$
- Interpolate $$\alpha_{meas} = \alpha(RH_{meas})$$ from the stored quenching curve
- Compute compensated Isobutylene concentration:
$$
C_{comp} = \frac{C_{raw}}{\alpha_{meas}}
$$
If RH ≥ 95% or condensation is detected:
- PID readings shall be flagged as UNRELIABLE.
- Unreliable values shall not be used in risk scoring; they may be logged for diagnostics only.
3.1.4 Requirement
The cloud layer shall receive only $$C_{comp}$$ and status flags (e.g. pid_status = OK / QUENCHED / UNRELIABLE).
Raw PID values $$C_{raw}$$ are optional, diagnostics‑only fields.
3.2 NDIR CO₂ Temperature/Pressure Compensation
3.2.1 Purpose
To correct NDIR CO₂ readings for variations in ambient temperature (T) and pressure (p) affecting gas density and optical absorption, ensuring consistent concentration accuracy.
3.2.2 Calibration Reference
Define a reference operating point:
- Temperature: $$T_{cal}$$ (e.g. 25 °C)
- Pressure: $$p_{cal}$$ (e.g. 1013 hPa)
- CO₂ reference gases per manufacturer guidance (e.g. 400, 1000, 2000 ppm).
From manufacturer data and/or calibration, derive T/p correction behavior (tables or polynomial coefficients).
3.2.3 On‑Node Compensation Function (Ideal Gas Approximation)
For each acquisition cycle:
- Read raw CO₂: $$C_{raw}$$
- Read instantaneous temperature $$T$$ (Kelvin) and pressure $$p$$ (Pa/hPa).
- Compute normalization factor:
$$
k_{TP} = \frac{p}{p_{cal}} \cdot \frac{T_{cal}}{T}
$$
- Compute compensated CO₂ concentration:
$$
C_{comp} = C_{raw} \cdot k_{TP}
$$
Advanced implementations may replace this with a manufacturer‑approved 2D polynomial or lookup table in T and p.
3.2.4 Requirement
All CO₂ values sent to the cloud shall be temperature/pressure‑compensated $$C_{comp}$$.
Raw $$C_{raw}$$ may be included as an optional diagnostic field; cloud‑side analytics shall not rely on uncompensated readings.
4.0 EMBEDDED FIRMWARE AND STATE MACHINE
The device shall never enter an undefined state.
Each node shall always be in exactly one of the six deterministic states:
- STATE_INIT (Initialization / POST)
- STATE_WARMUP (Sensor stabilization)
- STATE_NORMAL (Full operation)
- STATE_PURGE (Active chamber purge)
- STATE_DEGRADED (Limited operation)
- STATE_FAULT (Critical fault / shutdown)
4.1 STATE_INIT (Initialization)
- Trigger: Power‑up or hardware reset.
- Actions:
- Execute POST (Power‑On Self Test).
- Check memory integrity (EEPROM/Flash).
- Ping all sensor buses (I²C/SPI/UART).
- Transition:
- All checks OK and time < 10 s → STATE_WARMUP
- Any failure or timeout ≥ 10 s → STATE_FAULT
4.2 STATE_WARMUP (Warm‑Up)
- Purpose: Allow optical and thermal sensors to reach stable reference conditions.
- Actions:
- PID UV lamp ignition and stabilization.
- NDIR dual‑channel reference zeroing.
- Sensor readings are taken but not marked as valid for the cloud.
- Transition:
- Minimum warm‑up time elapsed (e.g. 180 s) and temperature drift below threshold (e.g. $$\Delta T < 0.05 °C/min$$) → STATE_NORMAL
- Any critical sensor health failure or warm‑up timeout (e.g. 900 s) → STATE_FAULT
4.3 STATE_NORMAL (Operational)
- Purpose: Main operating mode; full sensing, compensation and risk evaluation.
- Actions:
- Read all sensors.
- Apply humidity/temperature/pressure compensation (PID and NDIR functions).
- Compute aerosol‑cluster risk score using cross‑referenced signals.
- Publish telemetry via MQTT.
- Transitions:
- Chamber saturation / contamination (e.g. RH ≥ 95%, dust above threshold) → STATE_PURGE
- Non‑critical sensor failure (e.g. humidity sensor) → STATE_DEGRADED
- Critical hardware/energy fault (e.g. battery SoC < 5%, VCC instability, critical MCU error) → STATE_FAULT
4.4 STATE_PURGE (Active Cleaning)
- Purpose: Clear dust, exhaust, fog, or condensation from the sensor chamber.
- Actions:
- Suspend normal data acquisition and telemetry (send a single “PURGE MODE” flag to the cloud).
- Run micro‑compressor / fan at maximum speed to flush the chamber.
- Transition:
- After a fixed purge duration (e.g. ≥ 30 s), stop purge and return to STATE_WARMUP for restabilization.
4.5 STATE_DEGRADED (Limited Operation)
- Purpose: Maintain partial functionality when non‑critical sensors fail.
- Actions:
- Bypass failed non‑critical sensors (e.g. RH sensor).
- Disable associated compensation algorithms.
- Simplify risk model accordingly.
- Decrease
RELIABILITY_SCOREand mark node as “degraded” on the map. - Transition:
- If failed sensor recovers and readings stabilize → STATE_WARMUP
- If situation worsens into a critical fault (e.g. primary sensor or power) → STATE_FAULT
4.6 STATE_FAULT (Critical Fault)
- Purpose: Protect hardware and prevent invalid data usage.
- Actions:
- Cut power to all sensors, pumps and actuators.
- Send a single SOS / “Last Gasp” message (e.g. “Battery Low”, “Primary Sensor Failure”).
- Enter Deep‑Sleep or wait for hardware reset.
- Transition:
- Only hardware reset or power cycle can return the node to STATE_INIT.
5.0 SYSTEM SAFETY AND “RED LINE” RULES
5.1 Active Cross‑Reference Condition for Red Alarm
The system shall not raise a Red Risk (Aerosol Cluster) alarm until all of the following are simultaneously verified within a defined time window:
- Wind speed below threshold (stagnant air; e.g. $$v < 0.5$$ m/s).
- Positive gradient in local CO₂ concentration (indicating human breath accumulation).
- Tracer gas (Isobutylene) signal remaining persistent / non‑dispersed within the same window.
If any of these conditions is not met, only lower‑level warnings or “monitoring” status may be issued.
5.2 Watchdog Timer (WDT) Requirement
- The microcontroller shall feed the hardware Watchdog Timer only after successful completion of:
- The full processing loop in NORMAL/DEGRADED mode, and/or
- Valid state transitions (INIT → WARMUP → NORMAL, etc.).
- If any critical error prevents the loop from completing, WDT expiration shall force a hardware reset, ensuring the node cannot remain in an undefined or locked state.
5.3 Fault Isolation
- The system shall never continue normal processing with known corrupted or invalid sensor data.
- Upon detection of a hardware or sensor fault:
- The node shall automatically transition to STATE_DEGRADED or STATE_FAULT as appropriate.
- Faulty sensor inputs shall be excluded from compensation and risk algorithms.
5.3 MQTT TELEMETRY PACKET STRUCTURE
5.3.1 General Principle
- All node → cloud communication shall use MQTT with JSON payloads.
- QoS 1 is recommended as default for telemetry, balancing reliability and bandwidth on Cat‑M1 networks.
5.3.2 Topic Structure (Example)
hivescout/<city>/<street_id>/<node_id>/telemetryhivescout/<city>/<street_id>/<node_id>/statushivescout/<city>/<street_id>/<node_id>/alert
5.3.3 Telemetry Payload Fields (NORMAL/DEGRADED)
Example JSON payload:
{
"device_id": "NODE-IST-0001",
"fw_version": "2.0.0",
"timestamp_utc": "2026-04-11T04:30:15Z",
"state": "NORMAL", // INIT, WARMUP, NORMAL, PURGE, DEGRADED, FAULT
"reliability_score": 0.98, // 0.0 - 1.0
"co2_ppm": 650.2, // NDIR, T/P compensated
"co2_raw_ppm": 642.0, // optional
"pid_isobutylene_ppb": 12.5, // compensated
"pid_status": "OK", // OK, QUENCHED, UNRELIABLE
"rh_percent": 72.3,
"temp_c": 18.6,
"pressure_hpa": 1009.4,
"wind_speed_ms": 0.3,
"wind_dir_deg": 210,
"battery_soc": 0.81, // 0.0 - 1.0
"vcc_volts": 3.29,
"flags": {
"crossref_ok": true,
"purge_recent": false,
"sensor_fault": false,
"degraded_mode": false
}
}
5.3.4 Alert Payload (Red Risk)
{
"device_id": "NODE-IST-0001",
"timestamp_utc": "2026-04-11T04:30:15Z",
"alert_type": "AEROSOL_CLUSTER_RISK",
"risk_score": 0.91,
"reason": {
"low_wind": true,
"co2_gradient": true,
"pid_plume_persistent": true
},
"state": "NORMAL",
"reliability_score": 0.95
}
5.3.5 Requirements
- Every telemetry packet must include
stateandreliability_score, reflecting the on‑node state machine and degraded‑mode policy. - Flags such as
pid_status,sensor_fault,degraded_modeare mandatory to prevent cloud‑side AI from making decisions based on unreliable data. - Field names and units are part of the SRD baseline; changes require a controlled major revision.
If you want, I can now condense this into a clean “SRD v2.0” PDF‑style text layout (still as plain text/markdown) ready to be dropped into a document editor, with a front page and revision history block.
Bir yanıt yazın