# ALM Synchronization Report - Features and Requirements

**Date:** 2025-01-19  
**Purpose:** Compare current feature files and system requirements against ALM export  
**Reference:** `traceability_export.csv`

## Executive Summary

| Metric | ALM | Current Documentation | Missing in ALM | Status |
|--------|-----|----------------------|----------------|--------|
| **Total Features** | 27 | 39 | 12 | ⚠️ 12 new features need to be added |
| **Total System Requirements** | 93 | 139 | 46 | ⚠️ 46 new requirements need to be added |
| **Feature Groups** | 8 | 10 | 2 | ⚠️ 2 new feature groups (PWR, HW) |

---

## 1. Missing Features in ALM

The following features exist in current documentation but are **NOT** in ALM:

| Feature ID | Feature Name | Feature Group | Status | Priority |
|------------|--------------|---------------|--------|----------|
| **F-DAQ-04** | Sensor State Management | DAQ | ⚠️ MISSING | HIGH |
| **F-DQC-05** | Redundant Sensor Support | DQC | ⚠️ MISSING | MEDIUM |
| **F-COM-04** | Long-Range Fallback Communication | COM | ⚠️ MISSING | LOW (Optional) |
| **F-DIAG-04** | Layered Watchdog System | DIAG | ⚠️ MISSING | HIGH |
| **F-DATA-04** | Power-Loss Data Protection | DATA | ⚠️ MISSING | HIGH |
| **F-OTA-05** | A/B Partitioning with Rollback | OTA | ⚠️ MISSING | HIGH |
| **F-SEC-04** | Security Violation Handling | SEC | ⚠️ MISSING | HIGH |
| **F-SYS-05** | GPIO & Hardware Discipline | SYS | ⚠️ MISSING | MEDIUM |
| **F-PWR-01** | Brownout Detection and Handling | PWR | ⚠️ MISSING | HIGH |
| **F-PWR-02** | Power-Loss Recovery | PWR | ⚠️ MISSING | HIGH |
| **F-HW-01** | Sensor Abstraction Layer (SAL) | HW | ⚠️ MISSING | HIGH |
| **F-HW-02** | Hardware Interface Abstraction | HW | ⚠️ MISSING | HIGH |

**Total Missing Features:** 12

---

## 2. Missing System Requirements in ALM

The following system requirements exist in current documentation but are **NOT** in ALM:

### 2.1 Data Acquisition (DAQ) - Missing Requirements

| SR ID | Requirement Description | Related Feature | Status |
|-------|------------------------|-----------------|--------|
| **SR-DAQ-011** | The system shall track sensor operational states (INIT, WARMUP, STABLE, DEGRADED, FAILED). | F-DAQ-04 | ⚠️ MISSING |
| **SR-DAQ-012** | The system shall never publish raw sensor values without an accompanying validity flag indicating the current state. | F-DAQ-04 | ⚠️ MISSING |
| **SR-DAQ-013** | The system shall enforce sensor warmup durations (CO2: 30 seconds, Temperature: 5 seconds, others: sensor-specific). | F-DAQ-04 | ⚠️ MISSING |

### 2.2 Data Quality & Calibration (DQC) - Missing Requirements

| SR ID | Requirement Description | Related Feature | Status |
|-------|------------------------|-----------------|--------|
| **SR-DQC-016** | The system shall support redundant sensors for critical parameters (CO2, NH3) using different technologies or interfaces. | F-DQC-05 | ⚠️ MISSING |
| **SR-DQC-017** | The system shall implement sensor fusion algorithm to combine redundant sensor data (average, weighted, or voting mechanism). | F-DQC-05 | ⚠️ MISSING |
| **SR-DQC-018** | The system shall ensure that every critical parameter has two qualified sensor options to avoid common-mode failures. | F-DQC-05 | ⚠️ MISSING |

### 2.3 Communication (COM) - Missing Requirements

| SR ID | Requirement Description | Related Feature | Status |
|-------|------------------------|-----------------|--------|
| **SR-COM-011** | The system shall implement a heartbeat mechanism with 10-second interval and 30-second timeout. | F-COM-01 | ⚠️ MISSING |
| **SR-COM-012** | The system shall use CBOR encoding for all MQTT payloads. | F-COM-01 | ⚠️ MISSING |
| **SR-COM-013** | The system shall support automatic reconnection with exponential backoff on connection loss. | F-COM-01 | ⚠️ MISSING |
| **SR-COM-014** | The system shall encrypt all ESP-NOW peer communication using application-layer encryption (AES-128 minimum). | F-COM-03 | ⚠️ MISSING |
| **SR-COM-015** | The system shall implement acknowledgment and retry mechanism for ESP-NOW peer communication. | F-COM-03 | ⚠️ MISSING |
| **SR-COM-016** | The system may support long-range fallback communication using LoRa or cellular (LTE-M/NB-IoT) for farm-scale distances. | F-COM-04 | ⚠️ MISSING |
| **SR-COM-017** | If implemented, long-range fallback communication shall be used only for emergency alerts and data backup, not for OTA updates. | F-COM-04 | ⚠️ MISSING |

### 2.4 Diagnostics (DIAG) - Missing Requirements

| SR ID | Requirement Description | Related Feature | Status |
|-------|------------------------|-----------------|--------|
| **SR-DIAG-012** | The system shall implement Task Watchdog (Task WDT) to detect deadlocks in FreeRTOS tasks with a baseline timeout of 10 seconds. | F-DIAG-04 | ⚠️ MISSING |
| **SR-DIAG-013** | The system shall implement Interrupt Watchdog (Interrupt WDT) to detect hangs within ISRs with a baseline timeout of 3 seconds. | F-DIAG-04 | ⚠️ MISSING |
| **SR-DIAG-014** | The system shall implement RTC Watchdog (RTC WDT) as a final safety net for total system freezes with a baseline timeout of 30 seconds. | F-DIAG-04 | ⚠️ MISSING |

### 2.5 Data Persistence (DATA) - Missing Requirements

| SR ID | Requirement Description | Related Feature | Status |
|-------|------------------------|-----------------|--------|
| **SR-DATA-010** | The system shall detect brownout conditions using hardware brownout detector (BOD) at 3.0V threshold. | F-DATA-04 | ⚠️ MISSING |
| **SR-DATA-011** | The system shall immediately flush critical data buffers to non-volatile storage upon brownout detection. | F-DATA-04 | ⚠️ MISSING |
| **SR-DATA-012** | The system shall complete data flush operations within supercapacitor runtime (1-2 seconds) during brownout. | F-DATA-04 | ⚠️ MISSING |
| **SR-DATA-013** | The system shall implement wear-aware batch writing to prevent SD card wear. | F-DATA-04 | ⚠️ MISSING |

### 2.6 Firmware Update (OTA) - Missing Requirements

| SR ID | Requirement Description | Related Feature | Status |
|-------|------------------------|-----------------|--------|
| **SR-OTA-014** | The system shall implement A/B partitioning for safe firmware updates. | F-OTA-05 | ⚠️ MISSING |
| **SR-OTA-015** | The system shall automatically rollback to previous firmware if new firmware fails validation or health check. | F-OTA-05 | ⚠️ MISSING |
| **SR-OTA-016** | The system shall report rollback events to the Main Hub. | F-OTA-05 | ⚠️ MISSING |

### 2.7 Security (SEC) - Missing Requirements

| SR ID | Requirement Description | Related Feature | Status |
|-------|------------------------|-----------------|--------|
| **SR-SEC-013** | The system shall report security violations as FATAL diagnostic events. | F-SEC-04 | ⚠️ MISSING |
| **SR-SEC-014** | The system shall implement eFuse-based anti-rollback to prevent downgrade attacks. | F-SEC-04 | ⚠️ MISSING |
| **SR-SEC-015** | The system shall protect cryptographic keys during power loss and system resets. | F-SEC-04 | ⚠️ MISSING |

### 2.8 System Management (SYS) - Missing Requirements

| SR ID | Requirement Description | Related Feature | Status |
|-------|------------------------|-----------------|--------|
| **SR-SYS-014** | The system shall enforce GPIO discipline by avoiding strapping pins (GPIO 0, 3, 45, 46) for general-purpose I/O. | F-SYS-05 | ⚠️ MISSING |
| **SR-SYS-015** | The system shall ensure all shared I2C buses have appropriate physical pull-up resistors (2.2kΩ - 4.7kΩ for 3.3V). | F-SYS-05 | ⚠️ MISSING |
| **SR-SYS-016** | The system shall use ADC1 for all analog sensors when Wi-Fi is active (ADC2 is not available with Wi-Fi). | F-SYS-05 | ⚠️ MISSING |
| **SR-SYS-017** | The system shall maintain a canonical GPIO map document as a single source of truth. | F-SYS-05 | ⚠️ MISSING |

### 2.9 Power & Fault Handling (PWR) - Missing Requirements (NEW Feature Group)

| SR ID | Requirement Description | Related Feature | Status |
|-------|------------------------|-----------------|--------|
| **SR-PWR-001** | The system shall monitor input voltage and detect brownout conditions below 3.0V. | F-PWR-01 | ⚠️ MISSING |
| **SR-PWR-002** | The system shall immediately flush critical data buffers to non-volatile storage upon brownout detection. | F-PWR-01 | ⚠️ MISSING |
| **SR-PWR-003** | The system shall enter graceful shutdown mode during brownout conditions. | F-PWR-01 | ⚠️ MISSING |
| **SR-PWR-004** | The system shall perform clean reboot after power stabilization. | F-PWR-01 | ⚠️ MISSING |
| **SR-PWR-005** | The system shall recover gracefully from power interruptions. | F-PWR-02 | ⚠️ MISSING |
| **SR-PWR-006** | The system shall verify data integrity after power restoration. | F-PWR-02 | ⚠️ MISSING |
| **SR-PWR-007** | The system shall restore system state from persistent storage after power restoration. | F-PWR-02 | ⚠️ MISSING |
| **SR-PWR-008** | The system shall report power-loss and recovery events via diagnostics. | F-PWR-02 | ⚠️ MISSING |

### 2.10 Hardware Abstraction (HW) - Missing Requirements (NEW Feature Group)

| SR ID | Requirement Description | Related Feature | Status |
|-------|------------------------|-----------------|--------|
| **SR-HW-001** | The system shall provide a Sensor Abstraction Layer (SAL) for all sensor access. | F-HW-01 | ⚠️ MISSING |
| **SR-HW-002** | The system shall prevent application layer from directly accessing sensor hardware. | F-HW-01 | ⚠️ MISSING |
| **SR-HW-003** | The system shall track sensor state (INIT, WARMUP, STABLE, DEGRADED, FAILED). | F-HW-01 | ⚠️ MISSING |
| **SR-HW-004** | The system shall provide sensor validation and health check functions. | F-HW-01 | ⚠️ MISSING |
| **SR-HW-005** | The system shall abstract all hardware interfaces (I2C, SPI, UART, ADC, GPIO) through driver layers. | F-HW-02 | ⚠️ MISSING |
| **SR-HW-006** | The system shall enforce GPIO discipline (no strapping pins, proper pull-ups, ADC1/ADC2 separation). | F-HW-02 | ⚠️ MISSING |
| **SR-HW-007** | The system shall maintain a canonical GPIO map document. | F-HW-02 | ⚠️ MISSING |
| **SR-HW-008** | The system shall detect and report hardware resource conflicts. | F-HW-02 | ⚠️ MISSING |

**Total Missing Requirements:** 46

---

## 3. Complete Feature-to-Requirement Coverage Matrix

This table shows **ALL** features and their related system requirements for easy ALM import:

| Feature ID | Feature Name | Feature Group | System Requirements | Requirement Count |
|------------|--------------|---------------|---------------------|-------------------|
| **F-DAQ-01** | Multi-Sensor Data Acquisition | DAQ | SR-DAQ-001, SR-DAQ-002, SR-DAQ-003 | 3 |
| **F-DAQ-02** | High-Frequency Sampling and Local Filtering | DAQ | SR-DAQ-004, SR-DAQ-005, SR-DAQ-006, SR-DAQ-010 | 4 |
| **F-DAQ-03** | Timestamped Sensor Data Generation | DAQ | SR-DAQ-007, SR-DAQ-008, SR-DAQ-009 | 3 |
| **F-DAQ-04** | Sensor State Management | DAQ | SR-DAQ-011, SR-DAQ-012, SR-DAQ-013 | 3 |
| **F-DQC-01** | Automatic Sensor Detection | DQC | SR-DQC-001, SR-DQC-002, SR-DQC-003 | 3 |
| **F-DQC-02** | Sensor Type Enforcement | DQC | SR-DQC-004, SR-DQC-005, SR-DQC-006 | 3 |
| **F-DQC-03** | Sensor Failure Detection | DQC | SR-DQC-007, SR-DQC-008, SR-DQC-009, SR-DQC-010 | 4 |
| **F-DQC-04** | Machine Constants & Calibration Management | DQC | SR-DQC-011, SR-DQC-012, SR-DQC-013, SR-DQC-014, SR-DQC-015 | 5 |
| **F-DQC-05** | Redundant Sensor Support | DQC | SR-DQC-016, SR-DQC-017, SR-DQC-018 | 3 |
| **F-COM-01** | Main Hub Communication | COM | SR-COM-001, SR-COM-002, SR-COM-003, SR-COM-004, SR-COM-011, SR-COM-012, SR-COM-013 | 7 |
| **F-COM-02** | On-Demand Data Broadcasting | COM | SR-COM-005, SR-COM-006, SR-COM-007 | 3 |
| **F-COM-03** | Peer Sensor Hub Communication | COM | SR-COM-008, SR-COM-009, SR-COM-010, SR-COM-014, SR-COM-015 | 5 |
| **F-COM-04** | Long-Range Fallback Communication | COM | SR-COM-016, SR-COM-017 | 2 |
| **F-DIAG-01** | Diagnostic Code Management | DIAG | SR-DIAG-001, SR-DIAG-002, SR-DIAG-003, SR-DIAG-004 | 4 |
| **F-DIAG-02** | Diagnostic Data Storage | DIAG | SR-DIAG-005, SR-DIAG-006, SR-DIAG-007 | 3 |
| **F-DIAG-03** | Diagnostic Session | DIAG | SR-DIAG-008, SR-DIAG-009, SR-DIAG-010, SR-DIAG-011 | 4 |
| **F-DIAG-04** | Layered Watchdog System | DIAG | SR-DIAG-012, SR-DIAG-013, SR-DIAG-014 | 3 |
| **F-DATA-01** | Persistent Sensor Data Storage | DATA | SR-DATA-001, SR-DATA-002, SR-DATA-003 | 3 |
| **F-DATA-02** | Data Persistence Abstraction (DP Component) | DATA | SR-DATA-004, SR-DATA-005, SR-DATA-006 | 3 |
| **F-DATA-03** | Safe Data Handling During State Transitions | DATA | SR-DATA-007, SR-DATA-008, SR-DATA-009 | 3 |
| **F-DATA-04** | Power-Loss Data Protection | DATA | SR-DATA-010, SR-DATA-011, SR-DATA-012, SR-DATA-013 | 4 |
| **F-OTA-01** | OTA Update Negotiation | OTA | SR-OTA-001, SR-OTA-002, SR-OTA-003 | 3 |
| **F-OTA-02** | Firmware Reception and Storage | OTA | SR-OTA-004, SR-OTA-005, SR-OTA-006 | 3 |
| **F-OTA-03** | Firmware Integrity Validation | OTA | SR-OTA-007, SR-OTA-008, SR-OTA-009 | 3 |
| **F-OTA-04** | Safe Firmware Activation | OTA | SR-OTA-010, SR-OTA-011, SR-OTA-012, SR-OTA-013 | 4 |
| **F-OTA-05** | A/B Partitioning with Rollback | OTA | SR-OTA-014, SR-OTA-015, SR-OTA-016 | 3 |
| **F-SEC-01** | Secure Boot | SEC | SR-SEC-001, SR-SEC-002, SR-SEC-003, SR-SEC-004 | 4 |
| **F-SEC-02** | Secure Flash Storage | SEC | SR-SEC-005, SR-SEC-006, SR-SEC-007, SR-SEC-008 | 4 |
| **F-SEC-03** | Encrypted Communication | SEC | SR-SEC-009, SR-SEC-010, SR-SEC-011, SR-SEC-012 | 4 |
| **F-SEC-04** | Security Violation Handling | SEC | SR-SEC-013, SR-SEC-014, SR-SEC-015 | 3 |
| **F-SYS-01** | System State Management | SYS | SR-SYS-001, SR-SYS-002, SR-SYS-003 | 3 |
| **F-SYS-02** | Controlled Teardown Mechanism | SYS | SR-SYS-004, SR-SYS-005, SR-SYS-006 | 3 |
| **F-SYS-03** | Status Indication (OLED-Based HMI) | SYS | SR-SYS-007, SR-SYS-008, SR-SYS-009, SR-SYS-010 | 4 |
| **F-SYS-04** | Debug & Engineering Sessions | SYS | SR-SYS-011, SR-SYS-012, SR-SYS-013 | 3 |
| **F-SYS-05** | GPIO & Hardware Discipline | SYS | SR-SYS-014, SR-SYS-015, SR-SYS-016, SR-SYS-017 | 4 |
| **F-PWR-01** | Brownout Detection and Handling | PWR | SR-PWR-001, SR-PWR-002, SR-PWR-003, SR-PWR-004 | 4 |
| **F-PWR-02** | Power-Loss Recovery | PWR | SR-PWR-005, SR-PWR-006, SR-PWR-007, SR-PWR-008 | 4 |
| **F-HW-01** | Sensor Abstraction Layer (SAL) | HW | SR-HW-001, SR-HW-002, SR-HW-003, SR-HW-004 | 4 |
| **F-HW-02** | Hardware Interface Abstraction | HW | SR-HW-005, SR-HW-006, SR-HW-007, SR-HW-008 | 4 |

**Total:** 39 Features, 139 System Requirements

---

## 4. Detailed Feature Import Table

Use this table to import features into ALM one by one:

| Feature ID | Feature Name | Feature Group | Description | Parent Feature Group | Priority |
|------------|--------------|---------------|-------------|---------------------|----------|
| **F-DAQ-04** | Sensor State Management | DAQ | The system tracks sensor operational states (INIT, WARMUP, STABLE, DEGRADED, FAILED). Raw values are never published without an accompanying validity flag indicating the current state. | FG-DAQ | HIGH |
| **F-DQC-05** | Redundant Sensor Support | DQC | For critical parameters (CO2, NH3), the system supports primary and backup sensors using different technologies or interfaces to avoid common-mode failures. System implements sensor fusion algorithm. | FG-DQC | MEDIUM |
| **F-COM-04** | Long-Range Fallback Communication | COM | The system supports optional long-range fallback communication using LoRa (External Module) or cellular (LTE-M/NB-IoT) for farm-scale distances where Wi-Fi may not reach. | FG-COM | LOW |
| **F-DIAG-04** | Layered Watchdog System | DIAG | The system implements multiple levels of watchdogs: Task WDT (10s), Interrupt WDT (3s), and RTC WDT (30s) to ensure responsiveness and detect deadlocks/hangs. | FG-DIAG | HIGH |
| **F-DATA-04** | Power-Loss Data Protection | DATA | The system detects brownout conditions (3.0V) and immediately flushes critical data buffers to non-volatile storage. Implements wear-aware batch writing to prevent SD card wear. | FG-DATA | HIGH |
| **F-OTA-05** | A/B Partitioning with Rollback | OTA | The system implements A/B partitioning for safe firmware updates with automatic rollback capability if new firmware fails validation or health check. | FG-OTA | HIGH |
| **F-SEC-04** | Security Violation Handling | SEC | The system detects and reports security violations (secure boot failures, authentication failures, message tampering, unauthorized access) as FATAL diagnostic events. | FG-SEC | HIGH |
| **F-SYS-05** | GPIO & Hardware Discipline | SYS | The system enforces strict GPIO discipline: no strapping pins, proper I2C pull-ups, ADC1/ADC2 separation, and maintains a canonical GPIO map document. | FG-SYS | MEDIUM |
| **F-PWR-01** | Brownout Detection and Handling | PWR | The system monitors input voltage and detects brownout conditions below 3.0V. Immediately flushes critical data buffers and enters graceful shutdown mode. | FG-PWR | HIGH |
| **F-PWR-02** | Power-Loss Recovery | PWR | The system recovers gracefully from power interruptions (< 1 second). Performs clean reboot, verifies data integrity, and restores system state from persistent storage. | FG-PWR | HIGH |
| **F-HW-01** | Sensor Abstraction Layer (SAL) | HW | The system provides a Sensor Abstraction Layer (SAL) for all sensor access. Prevents application layer from directly accessing sensor hardware. Tracks sensor state and provides validation functions. | FG-HW | HIGH |
| **F-HW-02** | Hardware Interface Abstraction | HW | The system abstracts all hardware interfaces (I2C, SPI, UART, ADC, GPIO) through driver layers. Enforces GPIO discipline and detects hardware resource conflicts. | FG-HW | HIGH |

---

## 5. Detailed System Requirement Import Table

Use this table to import system requirements into ALM one by one:

| SR ID | Requirement Description | Feature ID | Feature Name | Feature Group | Priority |
|------|------------------------|------------|--------------|---------------|----------|
| **SR-DAQ-011** | The system shall track sensor operational states (INIT, WARMUP, STABLE, DEGRADED, FAILED). | F-DAQ-04 | Sensor State Management | DAQ | HIGH |
| **SR-DAQ-012** | The system shall never publish raw sensor values without an accompanying validity flag indicating the current state. | F-DAQ-04 | Sensor State Management | DAQ | HIGH |
| **SR-DAQ-013** | The system shall enforce sensor warmup durations (CO2: 30 seconds, Temperature: 5 seconds, others: sensor-specific). | F-DAQ-04 | Sensor State Management | DAQ | HIGH |
| **SR-DQC-016** | The system shall support redundant sensors for critical parameters (CO2, NH3) using different technologies or interfaces. | F-DQC-05 | Redundant Sensor Support | DQC | MEDIUM |
| **SR-DQC-017** | The system shall implement sensor fusion algorithm to combine redundant sensor data (average, weighted, or voting mechanism). | F-DQC-05 | Redundant Sensor Support | DQC | MEDIUM |
| **SR-DQC-018** | The system shall ensure that every critical parameter has two qualified sensor options to avoid common-mode failures. | F-DQC-05 | Redundant Sensor Support | DQC | MEDIUM |
| **SR-COM-011** | The system shall implement a heartbeat mechanism with 10-second interval and 30-second timeout. | F-COM-01 | Main Hub Communication | COM | HIGH |
| **SR-COM-012** | The system shall use CBOR encoding for all MQTT payloads. | F-COM-01 | Main Hub Communication | COM | HIGH |
| **SR-COM-013** | The system shall support automatic reconnection with exponential backoff on connection loss. | F-COM-01 | Main Hub Communication | COM | HIGH |
| **SR-COM-014** | The system shall encrypt all ESP-NOW peer communication using application-layer encryption (AES-128 minimum). | F-COM-03 | Peer Sensor Hub Communication | COM | HIGH |
| **SR-COM-015** | The system shall implement acknowledgment and retry mechanism for ESP-NOW peer communication. | F-COM-03 | Peer Sensor Hub Communication | COM | HIGH |
| **SR-COM-016** | The system may support long-range fallback communication using LoRa or cellular (LTE-M/NB-IoT) for farm-scale distances. | F-COM-04 | Long-Range Fallback Communication | COM | LOW |
| **SR-COM-017** | If implemented, long-range fallback communication shall be used only for emergency alerts and data backup, not for OTA updates. | F-COM-04 | Long-Range Fallback Communication | COM | LOW |
| **SR-DIAG-012** | The system shall implement Task Watchdog (Task WDT) to detect deadlocks in FreeRTOS tasks with a baseline timeout of 10 seconds. | F-DIAG-04 | Layered Watchdog System | DIAG | HIGH |
| **SR-DIAG-013** | The system shall implement Interrupt Watchdog (Interrupt WDT) to detect hangs within ISRs with a baseline timeout of 3 seconds. | F-DIAG-04 | Layered Watchdog System | DIAG | HIGH |
| **SR-DIAG-014** | The system shall implement RTC Watchdog (RTC WDT) as a final safety net for total system freezes with a baseline timeout of 30 seconds. | F-DIAG-04 | Layered Watchdog System | DIAG | HIGH |
| **SR-DATA-010** | The system shall detect brownout conditions using hardware brownout detector (BOD) at 3.0V threshold. | F-DATA-04 | Power-Loss Data Protection | DATA | HIGH |
| **SR-DATA-011** | The system shall immediately flush critical data buffers to non-volatile storage upon brownout detection. | F-DATA-04 | Power-Loss Data Protection | DATA | HIGH |
| **SR-DATA-012** | The system shall complete data flush operations within supercapacitor runtime (1-2 seconds) during brownout. | F-DATA-04 | Power-Loss Data Protection | DATA | HIGH |
| **SR-DATA-013** | The system shall implement wear-aware batch writing to prevent SD card wear. | F-DATA-04 | Power-Loss Data Protection | DATA | HIGH |
| **SR-OTA-014** | The system shall implement A/B partitioning for safe firmware updates. | F-OTA-05 | A/B Partitioning with Rollback | OTA | HIGH |
| **SR-OTA-015** | The system shall automatically rollback to previous firmware if new firmware fails validation or health check. | F-OTA-05 | A/B Partitioning with Rollback | OTA | HIGH |
| **SR-OTA-016** | The system shall report rollback events to the Main Hub. | F-OTA-05 | A/B Partitioning with Rollback | OTA | HIGH |
| **SR-SEC-013** | The system shall report security violations as FATAL diagnostic events. | F-SEC-04 | Security Violation Handling | SEC | HIGH |
| **SR-SEC-014** | The system shall implement eFuse-based anti-rollback to prevent downgrade attacks. | F-SEC-04 | Security Violation Handling | SEC | HIGH |
| **SR-SEC-015** | The system shall protect cryptographic keys during power loss and system resets. | F-SEC-04 | Security Violation Handling | SEC | HIGH |
| **SR-SYS-014** | The system shall enforce GPIO discipline by avoiding strapping pins (GPIO 0, 3, 45, 46) for general-purpose I/O. | F-SYS-05 | GPIO & Hardware Discipline | SYS | MEDIUM |
| **SR-SYS-015** | The system shall ensure all shared I2C buses have appropriate physical pull-up resistors (2.2kΩ - 4.7kΩ for 3.3V). | F-SYS-05 | GPIO & Hardware Discipline | SYS | MEDIUM |
| **SR-SYS-016** | The system shall use ADC1 for all analog sensors when Wi-Fi is active (ADC2 is not available with Wi-Fi). | F-SYS-05 | GPIO & Hardware Discipline | SYS | MEDIUM |
| **SR-SYS-017** | The system shall maintain a canonical GPIO map document as a single source of truth. | F-SYS-05 | GPIO & Hardware Discipline | SYS | MEDIUM |
| **SR-PWR-001** | The system shall monitor input voltage and detect brownout conditions below 3.0V. | F-PWR-01 | Brownout Detection and Handling | PWR | HIGH |
| **SR-PWR-002** | The system shall immediately flush critical data buffers to non-volatile storage upon brownout detection. | F-PWR-01 | Brownout Detection and Handling | PWR | HIGH |
| **SR-PWR-003** | The system shall enter graceful shutdown mode during brownout conditions. | F-PWR-01 | Brownout Detection and Handling | PWR | HIGH |
| **SR-PWR-004** | The system shall perform clean reboot after power stabilization. | F-PWR-01 | Brownout Detection and Handling | PWR | HIGH |
| **SR-PWR-005** | The system shall recover gracefully from power interruptions. | F-PWR-02 | Power-Loss Recovery | PWR | HIGH |
| **SR-PWR-006** | The system shall verify data integrity after power restoration. | F-PWR-02 | Power-Loss Recovery | PWR | HIGH |
| **SR-PWR-007** | The system shall restore system state from persistent storage after power restoration. | F-PWR-02 | Power-Loss Recovery | PWR | HIGH |
| **SR-PWR-008** | The system shall report power-loss and recovery events via diagnostics. | F-PWR-02 | Power-Loss Recovery | PWR | HIGH |
| **SR-HW-001** | The system shall provide a Sensor Abstraction Layer (SAL) for all sensor access. | F-HW-01 | Sensor Abstraction Layer (SAL) | HW | HIGH |
| **SR-HW-002** | The system shall prevent application layer from directly accessing sensor hardware. | F-HW-01 | Sensor Abstraction Layer (SAL) | HW | HIGH |
| **SR-HW-003** | The system shall track sensor state (INIT, WARMUP, STABLE, DEGRADED, FAILED). | F-HW-01 | Sensor Abstraction Layer (SAL) | HW | HIGH |
| **SR-HW-004** | The system shall provide sensor validation and health check functions. | F-HW-01 | Sensor Abstraction Layer (SAL) | HW | HIGH |
| **SR-HW-005** | The system shall abstract all hardware interfaces (I2C, SPI, UART, ADC, GPIO) through driver layers. | F-HW-02 | Hardware Interface Abstraction | HW | HIGH |
| **SR-HW-006** | The system shall enforce GPIO discipline (no strapping pins, proper pull-ups, ADC1/ADC2 separation). | F-HW-02 | Hardware Interface Abstraction | HW | HIGH |
| **SR-HW-007** | The system shall maintain a canonical GPIO map document. | F-HW-02 | Hardware Interface Abstraction | HW | HIGH |
| **SR-HW-008** | The system shall detect and report hardware resource conflicts. | F-HW-02 | Hardware Interface Abstraction | HW | HIGH |

**Total Missing Requirements:** 46

---

## 6. Feature Group Summary

| Feature Group | Features in ALM | Features in Current | Missing Features | Missing Requirements |
|---------------|-----------------|---------------------|------------------|---------------------|
| **DAQ** | 3 | 4 | 1 (F-DAQ-04) | 3 (SR-DAQ-011, SR-DAQ-012, SR-DAQ-013) |
| **DQC** | 4 | 5 | 1 (F-DQC-05) | 3 (SR-DQC-016, SR-DQC-017, SR-DQC-018) |
| **COM** | 3 | 4 | 1 (F-COM-04) | 7 (SR-COM-011 through SR-COM-017) |
| **DIAG** | 3 | 4 | 1 (F-DIAG-04) | 3 (SR-DIAG-012, SR-DIAG-013, SR-DIAG-014) |
| **DATA** | 3 | 4 | 1 (F-DATA-04) | 4 (SR-DATA-010 through SR-DATA-013) |
| **OTA** | 4 | 5 | 1 (F-OTA-05) | 3 (SR-OTA-014, SR-OTA-015, SR-OTA-016) |
| **SEC** | 3 | 4 | 1 (F-SEC-04) | 3 (SR-SEC-013, SR-SEC-014, SR-SEC-015) |
| **SYS** | 4 | 5 | 1 (F-SYS-05) | 4 (SR-SYS-014 through SR-SYS-017) |
| **PWR** | 0 | 2 | 2 (F-PWR-01, F-PWR-02) | 8 (SR-PWR-001 through SR-PWR-008) |
| **HW** | 0 | 2 | 2 (F-HW-01, F-HW-02) | 8 (SR-HW-001 through SR-HW-008) |
| **TOTAL** | **27** | **39** | **12** | **46** |

---

## 7. Import Priority Recommendations

### High Priority (Must Import First)

1. **F-PWR-01, F-PWR-02** + 8 requirements - Critical for power-loss protection
2. **F-HW-01, F-HW-02** + 8 requirements - Foundation for hardware abstraction
3. **F-DAQ-04** + 3 requirements - Sensor state management is critical
4. **F-DIAG-04** + 3 requirements - Watchdog system is essential
5. **F-DATA-04** + 4 requirements - Power-loss data protection
6. **F-OTA-05** + 3 requirements - A/B partitioning for safe updates
7. **F-SEC-04** + 3 requirements - Security violation handling
8. **F-COM-01 updates** (SR-COM-011, SR-COM-012, SR-COM-013) - Heartbeat and encoding
9. **F-COM-03 updates** (SR-COM-014, SR-COM-015) - ESP-NOW security

### Medium Priority

1. **F-DQC-05** + 3 requirements - Redundant sensor support
2. **F-SYS-05** + 4 requirements - GPIO discipline

### Low Priority (Optional)

1. **F-COM-04** + 2 requirements - Long-range fallback (optional feature)

---

## 8. ALM Import Instructions

### Step 1: Import New Feature Groups

First, create the new feature groups in ALM:
- **FG-PWR** (Power & Fault Handling Features)
- **FG-HW** (Hardware Abstraction Features)

### Step 2: Import Features

Import features from **Section 4** (Detailed Feature Import Table) in priority order.

### Step 3: Import System Requirements

Import system requirements from **Section 5** (Detailed System Requirement Import Table) and link them to their respective features.

### Step 4: Verify Traceability

After import, verify that:
- All features have their requirements linked
- All requirements trace to features
- Parent-child relationships are correct

---

## 9. Coverage Statistics

| Category | Count | Coverage |
|----------|-------|----------|
| **Features in ALM** | 27 | 69.2% |
| **Features in Current** | 39 | 100% |
| **Missing Features** | 12 | 30.8% |
| **Requirements in ALM** | 93 | 66.9% |
| **Requirements in Current** | 139 | 100% |
| **Missing Requirements** | 46 | 33.1% |

---

## 10. Notes

1. **Feature Groups PWR and HW are completely new** - These need to be created in ALM first
2. **Some requirements may need updates** - Existing requirements in ALM may need to be updated to match current documentation
3. **Traceability must be maintained** - When importing, ensure all requirements are linked to their features
4. **Priority order recommended** - Import high-priority items first to maintain system integrity

---

**Document Status:** Ready for ALM Import  
**Last Updated:** 2025-01-19
