(Atmospheric Early Grid Inspection System / Atmosferik Erken Izgara Denetim Sistemi)

Below is the fully integrated SRD v3.0 for HIVE SCOUT, including:

• Gas + environmental sensing
• Electro‑Optical Sensing Suite (thermal + digital night vision + active NIR scattering)
• Firmware state machine
• Telemetry
• Power Budget & Energy Management

You can copy‑paste this as a single document.

---

SYSTEM REQUIREMENTS DOCUMENT (SRD) – v3.0

Project Name: HIVE SCOUT (KOVAN İZCİ)
System Class: Industrial / Defense‑Grade Atmospheric Sensor Network
Document Status: Frozen Baseline Architecture (Gas + Electro‑Optical + Power)

---

0.0 REVISION HISTORY

• v2.0 – Initial Baseline
• Core gas and environmental sensor suite
• Compensation algorithms (PID humidity, NDIR temperature/pressure)
• Deterministic firmware state machine
• MQTT/JSON telemetry structure
• v2.1 – Night/Day & Optional Optics
• Night vs. day operational considerations
• Low‑temperature handling for PID UV lamp
• Optional optical aerosol channel (laser/light)
• Optional night‑vision contextual module
• v2.2 – Electro‑Optical Suite
• Defined Electro‑Optical Sensing Suite (thermal, digital low‑light, active NIR scattering)
• Clarified fusion between gas sensors and electro‑optics
• v3.0 – Power & Energy Management
• Added Power Budget & Energy Management architecture
• Linked energy policies to firmware state machine and electro‑optical duty cycles

---

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 combines:

• High‑grade gas and environmental sensing (tracer gas, CO₂, RH/T/P, wind), and
• A multi‑layer Electro‑Optical Sensing Suite (thermal imaging, digital low‑light night vision, active NIR scattering),

to identify physical “air traps” where aerosols can accumulate and persist, generating real‑time risk maps for cities, critical infrastructure and defense operations.

1.2 Out‑of‑Scope Functions

• The system does not directly detect viruses, bacteria, or specific DNA/RNA signatures.
• It does not perform clinical diagnosis or individual health assessment.
• It provides statistical and physical risk indicators derived from gas, environmental, and electro‑optical signals.

1.3 Operational Environment

Field nodes shall operate outdoors under:

• Temperature: −20 °C to +50 °C
• Relative humidity: 0% to 100% (including condensation events)
• Meteorological conditions: rain, fog, dust, exhaust plumes
• Enclosures: minimum IP67 ingress protection

Preferred operational window:

• The primary aerosol‑cluster mapping mode is optimized for high‑humidity, low‑wind evening/night or early‑morning conditions.
• Daytime operation focuses primarily on background data collection and trend analysis, due to stronger convection and mixing.

---

2.0 HARDWARE AND SENSOR SUITE

2.1 Core Processing Unit

Each field node shall use a microcontroller with:

• ARM Cortex‑M4/M33 (or equivalent)
• Hardware FPU (floating‑point unit)
• Sufficient RAM/Flash to:
• Execute floating‑point sensor equations and compensation algorithms in millisecond‑scale cycles.
• Implement a deterministic state machine (INIT, WARMUP, NORMAL, PURGE, DEGRADED, FAULT).

Indicative minimums (to be refined in detailed design):

• CPU clock: ≥ 80 MHz
• Flash: ≥ 512 kB
• RAM: ≥ 128 kB

2.2 Gas and Environmental Sensor Matrix

Minimum performance requirements:

Sensor Type	Target Quantity	LOD	Typical Resolution	Max Error	Critical Environmental Blind Point
PID (10.6 eV lamp)	Isobutylene (C₄H₈)	1 ppb	≤ 0.5 ppb	±2%	≥ 95% RH, condensation on UV optics
Dual‑channel NDIR	CO₂ (human breath)	400 ppm	≤ 1 ppm	±15 ppm	Outside −20 °C / +50 °C
Capacitive polymer RH	Relative humidity (RH)	0% RH	≤ 0.1% RH	±1.0% RH	Direct condensation on sensor surface
Bandgap temperature	Temperature (T)	−40 °C	≤ 0.01 °C	±0.1 °C	Direct solar loading (radiant heating)
Ultrasonic anemometer	Wind vector $$\vec{v}$$	0.01 m/s	≤ 0.01 m/s	±2%	Heavy rain (ultrasonic path disruption)

Each sensor shall be factory‑ or lab‑calibrated. Calibration intervals and drift limits shall be defined in a separate sensor annex.

2.3 Mechanical Design and Active Purge

• Passive air intake is not acceptable.
• Each node shall include:
• A controlled‑flow air path pulling ambient air into the sensor chamber at a defined nominal flow rate.
• A micro‑compressor or turbine fan capable of reversing flow and actively purging the chamber under saturation conditions (dust, exhaust, fog, condensation).
• Purge duration and airflow shall be sufficient to restore chamber readings to defined baseline levels after a purge cycle.

---

2.4 ELECTRO‑OPTICAL SENSING SUITE

The Electro‑Optical Sensing Suite comprises three complementary layers:

1. Thermal Imaging (LWIR/MWIR)
2. Digital Low‑Light Night Vision (Ultra‑Low‑Light sCMOS)
3. Active NIR Illumination and Aerosol Mie Scattering

Together, they minimize optical blind spots for aerosol clusters, even under thermal equilibrium conditions.

2.4.1 Thermal Imaging (LWIR/MWIR)

Purpose

• Provide long‑wave or mid‑wave infrared imaging of the scene, mapping surface and plume temperature distributions (e.g. warm exhaust, hot/cold structures, large thermal plumes).

Requirements

• Spectral band: LWIR and/or MWIR, as per chosen sensor.
• Resolution and field of view: sufficient to cover the node’s sensing footprint (relevant street segment).
• Thermal sensitivity (NETD): sufficient to detect small temperature differences in plumes and surfaces.

Limitation

• In thermal equilibrium (aerosol temperature ≈ background), thermal contrast may be negligible; thermal imaging alone may not reveal aerosol clouds.

2.4.2 Digital Low‑Light Night Vision (Ultra‑Low‑Light sCMOS)

Physical Principle

• Human vision degrades significantly below ~0.1 lux.
• Ultra‑low‑light scientific CMOS (sCMOS) sensors with back‑illuminated (BSI) architectures can operate at ~0.0001 lux, counting single photons and amplifying them electronically.

Role in the System

• Operates in visible and Near‑Infrared (NIR, ~0.7–1.0 µm) bands.
• Even in extremely dark street canyons, sCMOS can accumulate scattered starlight, moonlight, or urban sky glow to produce a detailed topographic image.
• Provides digital night‑vision imagery that can be numerically processed and fused with gas and thermal data.

Requirements

• Ultra‑low‑light sCMOS sensor with high quantum efficiency in visible + NIR.
• Fully digital output; all pixels shall be accessible for algorithmic processing.
• Integration times and gain levels controllable by firmware, based on ambient light and mission profile.

2.4.3 Active NIR Illumination and Mie Scattering

Physical Principle

• In very dark conditions (no moon, heavy cloud, deep urban canyon), the node must generate its own tactical illumination.
• Pulsed NIR lasers/LEDs at 850 nm or 940 nm are invisible to the human eye but detectable by the sCMOS sensor.
• Aerosol particles scatter NIR light (Mie scattering), altering intensity and spatial patterns of returned light.

Role in the System

• NIR emitters project structured or wide‑field illumination into the monitored volume.
• The sCMOS camera observes how much of this NIR light is attenuated or scattered by aerosols and particulates.
• From these changes, the system estimates aerosol optical density along specific paths or within the field of view.

Requirements

• NIR sources:
• Wavelength: typically 850 nm and/or 940 nm.
• Operation: pulsed or modulated for ambient light rejection and better SNR.
• Eye‑safe output within regulatory limits.
• Firmware shall synchronize NIR emission with sCMOS exposure.
• Optical density estimates are treated as physical density indicators and fused with gas and thermal data.

2.4.4 Fusion of Thermal and NIR/sCMOS

Motivation

• Thermal imaging may miss plumes at thermal equilibrium; NIR scattering may miss purely thermal gradients with little particulate load.
• Fusing these channels provides:
• Thermal contrast where available, and
• Optical density contrast where temperature differences vanish.

Design Principle

• Thermal and NIR/sCMOS channels are co‑registered with the node’s sensing footprint.
• Electro‑optical outputs are time‑synchronized with gas and environmental data.
• Cloud‑side analytics use electro‑optical signals to:
• Confirm or refine gas‑based risk scores.
• Flag anomalies (e.g. high optical density without corresponding gas signal) for further investigation.

---

2.5 OPTIONAL NIGHT VISION MODULE (CONTEXTUAL)

Separately from the Electro‑Optical Sensing Suite, the system may include a contextual Night Vision Module:

• Low‑light / IR‑sensitive camera for situational awareness (human/vehicle presence, visible smoke, local obstructions).
• Optional IR illumination, with:
• Configurable streaming/recording policies,
• Privacy/anonymization controls,
• Alignment with node sensing footprint.
• Outputs used for scene understanding and operator decision support, not direct gas‑based risk scoring (unless explicitly configured in advanced analytics).

---

3.0 MATHEMATICAL COMPENSATION ALGORITHMS

3.1 PID Humidity Quenching Compensation

Calibration (Per Sensor)

• Fixed Isobutylene concentration $$C_{ref}$$ (e.g. 100 ppb).
• RH calibration points: 30%, 60%, 90%.
• For each point:

$$
\alpha(RH_i) = \frac{C_{raw}(RH_i)}{C_{raw}(RH_{ref})}
$$

Store $$\alpha(RH)$$ curve per sensor.

On‑Node Compensation

$$
C_{comp} = \frac{C_{raw}}{\alpha(RH_{meas})}
$$

• If RH ≥ 95% or condensation detected → pid_status = UNRELIABLE, PID excluded from risk scoring.

Low‑Temperature Handling

• PID UV lamp shall not be operated below vendor minimum temperature.
• Below that, pid_status = DISABLED, PID ignored in risk model.

3.2 NDIR CO₂ Temperature/Pressure Compensation

Reference

• $$T_{cal}$$, $$p_{cal}$$ defined per design.

On‑Node Compensation

$$
k_{TP} = \frac{p}{p_{cal}} \cdot \frac{T_{cal}}{T}, \quad C_{comp} = C_{raw} \cdot k_{TP}
$$

• Out‑of‑spec T/p → mark CO₂ UNRELIABLE; node may enter DEGRADED mode.

---

4.0 EMBEDDED FIRMWARE AND STATE MACHINE

4.1 Deterministic States

Each node is always in exactly one of:

• STATE_INIT – Initialization and POST
• STATE_WARMUP – Sensor stabilization
• STATE_NORMAL – Full operation
• STATE_PURGE – Active chamber purge
• STATE_DEGRADED – Limited operation
• STATE_FAULT – Critical fault / shutdown

No undefined states are allowed.

4.2 Priority of Transitions

Priority order:

1. Hardware safety → STATE_FAULT
2. Sensor health / chamber integrity → STATE_PURGE, STATE_WARMUP
3. Data production → STATE_NORMAL, STATE_DEGRADED

4.3 State Summaries

• INIT: POST, memory check, bus ping; < 10 s and all OK → WARMUP; else → FAULT.
• WARMUP: Stabilize sensors; no valid data sent; after min time and low thermal drift → NORMAL; failure/timeout → FAULT.
• NORMAL: Full sensing, compensation, risk scoring, telemetry; saturation → PURGE; non‑critical sensor failure → DEGRADED; critical fault → FAULT.
• PURGE: Stop normal sensing; run purge fan; send “PURGE” flag; after purge duration → WARMUP.
• DEGRADED: Bypass failed non‑critical sensors; simplified model; lower reliability; recovery → WARMUP; further faults → FAULT.
• FAULT: Cut power to sensors/actuators; optional SOS message; deep sleep or wait for reset; reset → INIT.

---

5.0 SYSTEM SAFETY, RED‑LINE RULES AND TELEMETRY

5.1 Red‑Line Condition for Red Risk

No Red Risk (Aerosol Cluster) alarm shall be raised unless all of:

1. Wind speed below threshold (e.g. $$v < 0.5$$ m/s).
2. Positive gradient in local CO₂ concentration.
3. Persistent tracer gas (Isobutylene) signal within the same time window.

Electro‑optical optical density may support the decision but shall not override these core conditions.

5.2 Watchdog Timer Policy

• WDT is fed only after a complete, successful processing loop and/or valid state transition.
• Any hang or loop failure → WDT timeout → hardware reset.

5.3 Fault Isolation

• System shall not remain in NORMAL mode using known bad data.
• Faults trigger DEGRADED or FAULT; faulty sensors excluded from algorithms.

5.4 MQTT Telemetry and Alerts

• Protocol: MQTT over 4G/LTE Cat‑M1 (or equivalent), JSON payload, QoS 1.
• Topics (example):
• hivescout/<city>/<street_id>/<node_id>/telemetry
• hivescout/<city>/<street_id>/<node_id>/status
• hivescout/<city>/<street_id>/<node_id>/alert

Telemetry fields (example): state, reliability_score, compensated and raw gas readings, RH/T/P, wind, optical_aerosol_od, power metrics (battery_soc, vcc_volts), flags (crossref_ok, sensor_fault, degraded_mode, etc.).

Alert payload: includes alert_type, risk_score, and detailed reason fields (low_wind, co2_gradient, pid_plume_persistent, optical_density_high, …).

---

6.0 POWER BUDGET & ENERGY MANAGEMENT

6.1 Overview

Each node is designed as an energy‑autonomous field device. The power system must:

• Support 24/7 operation in harsh conditions.
• Handle both baseline loads and peak loads (electro‑optics, PURGE, LTE).
• Enforce deterministic power‑down and load‑shedding behavior.

6.2 Power Domains

1. Core Domain – MCU, gas sensors, essential telemetry, safety functions.
2. Electro‑Optical Domain – Thermal camera, sCMOS, NIR illumination.
3. Mechanical Domain – Purge fan/compressor, other actuators.
4. Auxiliary Domain – Contextual night‑vision, indicators, maintenance interfaces.

Each domain’s consumption and control (on/off, duty cycle) are managed by firmware, linked to node state and battery SoC.

6.3 Battery and Solar

• Battery: LiFePO₄ pack designed for multiple days of autonomy (e.g. 3–5 days) under worst‑case winter conditions.
• Solar: panels sized for local insolation and daily energy budget, with safety margin for winter.
• Daily energy budget includes:
• Core domain 24/7 consumption,
• Electro‑optical duty‑cycle,
• PURGE frequency,
• Telemetry usage.

6.4 SoC‑Based Policies

• Define SoC thresholds: HIGH, MEDIUM, LOW, CRITICAL.
• HIGH: full functionality according to mission profile.
• MEDIUM: reduce optional loads, event‑triggered electro‑optics.
• LOW: restrict PURGE and electro‑optics; increase telemetry interval.
• CRITICAL: transition to safe state, send last message if possible, then deep sleep.

6.5 Power Fault Handling

• Voltage instability or abnormal power events are treated as hardware safety issues.
• Such events trigger a transition to STATE_FAULT, shutting down high‑current domains and preserving minimal logic for reset/recovery.

---

This is the full, combined engineering baseline. If you want, we can now derive from this a very compact “export‑controlled” or “classified/unclassified” version tailored for a defense procurement context, or a more public smart‑city spec sheet.