# Feature to System Requirements Traceability Matrix

**Version:** 2.0  
**Date:** 2025-01-19  
**Document Type:** Traceability Matrix  
**Scope:** ASF Sensor Hub (Sub-Hub)

## 1. Purpose

This document provides complete bidirectional traceability between Features and System Requirements (SR-*). It serves as a reference for:
- Requirements verification
- Impact analysis
- Change management
- Test coverage analysis

## 2. Traceability Overview

| Feature Group | Feature Count | System Requirements Count |
|---------------|---------------|---------------------------|
| DAQ (Data Acquisition) | 4 | 13 |
| DQC (Data Quality & Calibration) | 5 | 18 |
| COM (Communication) | 4 | 17 |
| DIAG (Diagnostics) | 4 | 14 |
| DATA (Persistence) | 4 | 13 |
| OTA (Firmware Update) | 5 | 16 |
| SEC (Security) | 4 | 15 |
| SYS (System Management) | 5 | 17 |
| PWR (Power & Fault Handling) | 2 | 8 |
| HW (Hardware Abstraction) | 2 | 8 |
| **TOTAL** | **39** | **139** |

## 3. Complete Feature to System Requirements Mapping

### 3.1 Data Acquisition Features (DAQ)

| Feature ID | Feature Name | System Requirements |
|------------|--------------|---------------------|
| F-DAQ-01 | Multi-Sensor Data Acquisition | SR-DAQ-001, SR-DAQ-002, SR-DAQ-003 |
| F-DAQ-02 | High-Frequency Sampling and Local Filtering | SR-DAQ-004, SR-DAQ-005, SR-DAQ-006, SR-DAQ-010 |
| F-DAQ-03 | Timestamped Sensor Data Generation | SR-DAQ-007, SR-DAQ-008, SR-DAQ-009 |
| F-DAQ-04 | Sensor State Management | SR-DAQ-011, SR-DAQ-012, SR-DAQ-013 |

**System Requirements Details:**

| SR ID | Requirement Description |
|-------|------------------------|
| SR-DAQ-001 | The system shall support acquisition of data from multiple environmental sensor types simultaneously. |
| SR-DAQ-002 | The system shall provide a dedicated software driver abstraction for each supported sensor type. |
| SR-DAQ-003 | The system shall acquire sensor data only from sensors detected as present and enabled. |
| SR-DAQ-004 | The system shall sample each enabled sensor multiple times within a single acquisition cycle (default: 10 samples). |
| SR-DAQ-005 | The system shall apply a local filtering mechanism to raw sensor samples to produce a single representative value. |
| SR-DAQ-006 | The system shall allow configuration of sampling count and filtering parameters via system configuration data (Machine Constants). |
| SR-DAQ-007 | The system shall associate each processed sensor value with a timestamp. |
| SR-DAQ-008 | The system shall generate timestamps after completion of filtering. |
| SR-DAQ-009 | The system shall include sensor identifier, sensor type, value, unit, timestamp, and validity status in each sensor data record. |
| SR-DAQ-010 | The system shall complete sensor acquisition cycle within a maximum of 100ms per sensor. |
| SR-DAQ-011 | The system shall track sensor operational states (INIT, WARMUP, STABLE, DEGRADED, FAILED). |
| SR-DAQ-012 | The system shall never publish raw sensor values without an accompanying validity flag indicating the current state. |
| SR-DAQ-013 | The system shall enforce sensor warmup durations (CO2: 30 seconds, Temperature: 5 seconds, others: sensor-specific). |

### 3.2 Data Quality & Calibration Features (DQC)

| Feature ID | Feature Name | System Requirements |
|------------|--------------|---------------------|
| F-DQC-01 | Automatic Sensor Detection | SR-DQC-001, SR-DQC-002, SR-DQC-003 |
| F-DQC-02 | Sensor Type Enforcement | SR-DQC-004, SR-DQC-005, SR-DQC-006 |
| F-DQC-03 | Sensor Failure Detection | SR-DQC-007, SR-DQC-008, SR-DQC-009, SR-DQC-010 |
| F-DQC-04 | Machine Constants & Calibration Management | SR-DQC-011, SR-DQC-012, SR-DQC-013, SR-DQC-014, SR-DQC-015 |
| F-DQC-05 | Redundant Sensor Support | SR-DQC-016, SR-DQC-017, SR-DQC-018 |

**System Requirements Details:**

| SR ID | Requirement Description |
|-------|------------------------|
| SR-DQC-001 | The system shall detect the presence of each sensor using a dedicated hardware detection mechanism. |
| SR-DQC-002 | The system shall perform sensor presence detection during system startup and after any reinitialization event. |
| SR-DQC-003 | The system shall initialize only those sensors that are detected as present. |
| SR-DQC-004 | The system shall assign each sensor slot to a predefined sensor type. |
| SR-DQC-005 | The system shall verify that the detected sensor matches the expected sensor type for the slot. |
| SR-DQC-006 | The system shall reject and report any sensor-slot mismatch as a diagnostic event. |
| SR-DQC-007 | The system shall continuously monitor sensor responsiveness and signal validity during operation. |
| SR-DQC-008 | The system shall detect sensor failures including disconnection, non-responsiveness, and invalid measurement ranges. |
| SR-DQC-009 | The system shall mark a failed sensor as defective and exclude it from data reporting. |
| SR-DQC-010 | The system shall report detected sensor failures to the Main Hub with timestamps and failure classification. |
| SR-DQC-011 | The system shall maintain a Machine Constants dataset defining sensor configuration, calibration parameters, and communication identifiers. |
| SR-DQC-012 | The system shall persist the Machine Constants dataset in non-volatile storage. |
| SR-DQC-013 | The system shall load and apply Machine Constants during system initialization. |
| SR-DQC-014 | The system shall support remote updates of the Machine Constants dataset initiated by the Main Hub. |
| SR-DQC-015 | The system shall apply updated Machine Constants only after executing a controlled teardown and reinitialization sequence. |
| SR-DQC-016 | The system shall support redundant sensors for critical parameters (CO2, NH3) using different technologies or interfaces. |
| SR-DQC-017 | The system shall implement sensor fusion algorithm to combine redundant sensor data (average, weighted, or voting mechanism). |
| SR-DQC-018 | The system shall ensure that every critical parameter has two qualified sensor options to avoid common-mode failures. |

### 3.3 Communication Features (COM)

| Feature ID | Feature Name | System Requirements |
|------------|--------------|---------------------|
| F-COM-01 | Main Hub Communication | SR-COM-001, SR-COM-002, SR-COM-003, SR-COM-004, SR-COM-011, SR-COM-012, SR-COM-013 |
| F-COM-02 | On-Demand Data Broadcasting | SR-COM-005, SR-COM-006, SR-COM-007 |
| F-COM-03 | Peer Sensor Hub Communication | SR-COM-008, SR-COM-009, SR-COM-010, SR-COM-014, SR-COM-015 |
| F-COM-04 | Long-Range Fallback Communication | SR-COM-016, SR-COM-017 |

**System Requirements Details:**

| SR ID | Requirement Description |
|-------|------------------------|
| SR-COM-001 | The system shall support bidirectional communication between the Sensor Hub and the Main Hub using MQTT over TLS 1.2. |
| SR-COM-002 | The system shall transmit sensor data, diagnostics, and system status information to the Main Hub via MQTT. |
| SR-COM-003 | The system shall receive commands, configuration updates, and firmware update requests from the Main Hub via MQTT. |
| SR-COM-004 | The system shall monitor and report the communication link status with the Main Hub. |
| SR-COM-005 | The system shall support on-demand requests from the Main Hub for sensor data. |
| SR-COM-006 | The system shall respond to on-demand data requests with the most recent timestamped sensor data within 100ms. |
| SR-COM-007 | The system shall include data validity and sensor status information in on-demand responses. |
| SR-COM-008 | The system shall support limited peer-to-peer communication between Sensor Hubs using ESP-NOW. |
| SR-COM-009 | The system shall allow peer communication for basic coordination functions such as connectivity checks or time synchronization. |
| SR-COM-010 | The system shall ensure that peer Sensor Hub communication does not interfere with Main Hub communication or control operations. |
| SR-COM-011 | The system shall implement a heartbeat mechanism with 10-second interval and 30-second timeout. |
| SR-COM-012 | The system shall use CBOR encoding for all MQTT payloads. |
| SR-COM-013 | The system shall support automatic reconnection with exponential backoff on connection loss. |
| SR-COM-014 | The system shall encrypt all ESP-NOW peer communication using application-layer encryption (AES-128 minimum). |
| SR-COM-015 | The system shall implement acknowledgment and retry mechanism for ESP-NOW peer communication. |
| SR-COM-016 | The system may support long-range fallback communication using LoRa or cellular (LTE-M/NB-IoT) for farm-scale distances. |
| SR-COM-017 | If implemented, long-range fallback communication shall be used only for emergency alerts and data backup, not for OTA updates. |

### 3.4 Diagnostics & Health Monitoring Features (DIAG)

| Feature ID | Feature Name | System Requirements |
|------------|--------------|---------------------|
| F-DIAG-01 | Diagnostic Code Management | SR-DIAG-001, SR-DIAG-002, SR-DIAG-003, SR-DIAG-004 |
| F-DIAG-02 | Diagnostic Data Storage | SR-DIAG-005, SR-DIAG-006, SR-DIAG-007 |
| F-DIAG-03 | Diagnostic Session | SR-DIAG-008, SR-DIAG-009, SR-DIAG-010, SR-DIAG-011 |
| F-DIAG-04 | Layered Watchdog System | SR-DIAG-012, SR-DIAG-013, SR-DIAG-014 |

**System Requirements Details:**

| SR ID | Requirement Description |
|-------|------------------------|
| SR-DIAG-001 | The system shall implement a diagnostic code framework for reporting system health, warnings, errors, and fatal faults. |
| SR-DIAG-002 | The system shall assign a unique diagnostic code to each detected fault or abnormal condition. |
| SR-DIAG-003 | The system shall classify diagnostic codes by severity level. |
| SR-DIAG-004 | The system shall associate each diagnostic event with a timestamp and source component. |
| SR-DIAG-005 | The system shall persist diagnostic events in non-volatile storage. |
| SR-DIAG-006 | The system shall retain diagnostic data across system resets and power cycles. |
| SR-DIAG-007 | The system shall implement a bounded diagnostic storage mechanism with a defined overwrite or rollover policy. |
| SR-DIAG-008 | The system shall provide a diagnostic session interface for accessing diagnostic data. |
| SR-DIAG-009 | The system shall allow authorized diagnostic sessions to retrieve stored diagnostic events. |
| SR-DIAG-010 | The system shall allow authorized diagnostic sessions to clear diagnostic records. |
| SR-DIAG-011 | The system shall ensure that diagnostic sessions do not interfere with normal sensor acquisition or communication operations. |
| SR-DIAG-012 | The system shall implement Task Watchdog (Task WDT) to detect deadlocks in FreeRTOS tasks with a baseline timeout of 10 seconds. |
| SR-DIAG-013 | The system shall implement Interrupt Watchdog (Interrupt WDT) to detect hangs within ISRs with a baseline timeout of 3 seconds. |
| 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. |

### 3.5 Persistence & Data Management Features (DATA)

| Feature ID | Feature Name | System Requirements |
|------------|--------------|---------------------|
| F-DATA-01 | Persistent Sensor Data Storage | SR-DATA-001, SR-DATA-002, SR-DATA-003 |
| F-DATA-02 | Data Persistence Abstraction (DP Component) | SR-DATA-004, SR-DATA-005, SR-DATA-006 |
| F-DATA-03 | Safe Data Handling During State Transitions | SR-DATA-007, SR-DATA-008, SR-DATA-009 |
| F-DATA-04 | Power-Loss Data Protection | SR-DATA-010, SR-DATA-011, SR-DATA-012, SR-DATA-013 |

**System Requirements Details:**

| SR ID | Requirement Description |
|-------|------------------------|
| SR-DATA-001 | The system shall persist timestamped sensor data in non-volatile storage. |
| SR-DATA-002 | The system shall store sensor data together with sensor identifiers, timestamps, and validity status. |
| SR-DATA-003 | The system shall support configurable data retention and overwrite policies. |
| SR-DATA-004 | The system shall provide a Data Persistence (DP) component as the sole interface for persistent data access. |
| SR-DATA-005 | The system shall prevent application and feature modules from directly accessing storage hardware. |
| SR-DATA-006 | The DP component shall support serialization and deserialization of structured system data. |
| SR-DATA-007 | The system shall ensure that all critical runtime data is flushed to non-volatile storage before entering a controlled teardown or reset. |
| SR-DATA-008 | The system shall protect data integrity during firmware updates and configuration changes. |
| SR-DATA-009 | The system shall verify successful data persistence before completing a state transition. |
| SR-DATA-010 | The system shall detect brownout conditions using hardware brownout detector (BOD) at 3.0V threshold. |
| SR-DATA-011 | The system shall immediately flush critical data buffers to non-volatile storage upon brownout detection. |
| SR-DATA-012 | The system shall complete data flush operations within supercapacitor runtime (1-2 seconds) during brownout. |
| SR-DATA-013 | The system shall implement wear-aware batch writing to prevent SD card wear. |

### 3.6 Firmware Update (OTA) Features

| Feature ID | Feature Name | System Requirements |
|------------|--------------|---------------------|
| F-OTA-01 | OTA Update Negotiation | SR-OTA-001, SR-OTA-002, SR-OTA-003 |
| F-OTA-02 | Firmware Reception and Storage | SR-OTA-004, SR-OTA-005, SR-OTA-006 |
| F-OTA-03 | Firmware Integrity Validation | SR-OTA-007, SR-OTA-008, SR-OTA-009 |
| F-OTA-04 | Safe Firmware Activation | SR-OTA-010, SR-OTA-011, SR-OTA-012, SR-OTA-013 |
| F-OTA-05 | A/B Partitioning with Rollback | SR-OTA-014, SR-OTA-015, SR-OTA-016 |

**System Requirements Details:**

| SR ID | Requirement Description |
|-------|------------------------|
| SR-OTA-001 | The system shall support OTA update negotiation initiated by the Main Hub. |
| SR-OTA-002 | The system shall verify internal readiness before accepting an OTA update request. |
| SR-OTA-003 | The system shall explicitly acknowledge or reject OTA requests. |
| SR-OTA-004 | The system shall receive firmware images over the established communication channel (HTTPS or MQTT). |
| SR-OTA-005 | The system shall store received firmware images in non-volatile storage (SD card) prior to validation. |
| SR-OTA-006 | The system shall prevent overwriting the active firmware during firmware reception. |
| SR-OTA-007 | The system shall validate the integrity of the received firmware image before activation using SHA-256 hash. |
| SR-OTA-008 | The system shall reject firmware images that fail integrity validation. |
| SR-OTA-009 | The system shall report firmware validation results to the Main Hub. |
| SR-OTA-010 | The system shall execute a controlled teardown before firmware activation. |
| SR-OTA-011 | The system shall persist critical runtime data and calibration data prior to firmware flashing. |
| SR-OTA-012 | The system shall activate new firmware only after successful integrity validation. |
| SR-OTA-013 | The system shall reboot into the new firmware after successful activation. |
| SR-OTA-014 | The system shall implement A/B partitioning for safe firmware updates. |
| SR-OTA-015 | The system shall automatically rollback to previous firmware if new firmware fails validation or health check. |
| SR-OTA-016 | The system shall report rollback events to the Main Hub. |

### 3.7 Security & Safety Features (SEC)

| Feature ID | Feature Name | System Requirements |
|------------|--------------|---------------------|
| F-SEC-01 | Secure Boot | SR-SEC-001, SR-SEC-002, SR-SEC-003, SR-SEC-004 |
| F-SEC-02 | Secure Flash Storage | SR-SEC-005, SR-SEC-006, SR-SEC-007, SR-SEC-008 |
| F-SEC-03 | Encrypted Communication | SR-SEC-009, SR-SEC-010, SR-SEC-011, SR-SEC-012 |
| F-SEC-04 | Security Violation Handling | SR-SEC-013, SR-SEC-014, SR-SEC-015 |

**System Requirements Details:**

| SR ID | Requirement Description |
|-------|------------------------|
| SR-SEC-001 | The system shall verify the authenticity of the firmware image before execution during every boot cycle using Secure Boot V2. |
| SR-SEC-002 | The system shall prevent execution of firmware images that fail cryptographic verification. |
| SR-SEC-003 | The system shall enter BOOT_FAILURE state upon secure boot verification failure. |
| SR-SEC-004 | The system shall protect the root-of-trust against modification (eFuse protection). |
| SR-SEC-005 | The system shall protect sensitive data stored in internal flash memory from unauthorized access using Flash Encryption (AES-256). |
| SR-SEC-006 | The system shall support encryption of sensitive data stored in external storage devices (SD card). |
| SR-SEC-007 | The system shall restrict access to cryptographic keys to authorized system components only. |
| SR-SEC-008 | The system shall ensure data integrity for stored configuration and machine constant files. |
| SR-SEC-009 | The system shall encrypt all communication with the Main Hub using TLS 1.2 with mutual authentication (mTLS). |
| SR-SEC-010 | The system shall ensure integrity and authenticity of all received and transmitted messages. |
| SR-SEC-011 | The system shall use secure communication channels for OTA firmware updates. |
| SR-SEC-012 | The system shall detect and report communication security violations. |
| SR-SEC-013 | The system shall report security violations as FATAL diagnostic events. |
| SR-SEC-014 | The system shall implement eFuse-based anti-rollback to prevent downgrade attacks. |
| SR-SEC-015 | The system shall protect cryptographic keys during power loss and system resets. |

### 3.8 System Management Features (SYS)

| Feature ID | Feature Name | System Requirements |
|------------|--------------|---------------------|
| F-SYS-01 | System State Management | SR-SYS-001, SR-SYS-002, SR-SYS-003 |
| F-SYS-02 | Controlled Teardown Mechanism | SR-SYS-004, SR-SYS-005, SR-SYS-006 |
| F-SYS-03 | Status Indication (OLED-Based HMI) | SR-SYS-007, SR-SYS-008, SR-SYS-009, SR-SYS-010 |
| F-SYS-04 | Debug & Engineering Sessions | SR-SYS-011, SR-SYS-012, SR-SYS-013 |
| F-SYS-05 | GPIO & Hardware Discipline | SR-SYS-014, SR-SYS-015, SR-SYS-016, SR-SYS-017 |

**System Requirements Details:**

| SR ID | Requirement Description |
|-------|------------------------|
| SR-SYS-001 | The system shall implement a defined finite state machine for operational control. |
| SR-SYS-002 | The system shall restrict operations based on the current system state. |
| SR-SYS-003 | The system shall notify system components of state transitions. |
| SR-SYS-004 | The system shall execute a controlled teardown sequence before firmware or machine constant updates. |
| SR-SYS-005 | The system shall persist all critical runtime data before completing teardown. |
| SR-SYS-006 | The system shall prevent data corruption during teardown and reset operations. |
| SR-SYS-007 | The system shall provide a local OLED display using I2C communication. |
| SR-SYS-008 | The system shall display connectivity status, system state, sensor summary, and time/date. |
| SR-SYS-009 | The system shall provide menu navigation using Up, Down, and Select buttons. |
| SR-SYS-010 | The system shall provide diagnostic, sensor, and health information via the local menu. |
| SR-SYS-011 | The system shall support diagnostic sessions for retrieving logs and system status. |
| SR-SYS-012 | The system shall support debug sessions for controlled engineering operations. |
| SR-SYS-013 | The system shall restrict debug actions to authorized sessions only. |
| SR-SYS-014 | The system shall enforce GPIO discipline by avoiding strapping pins (GPIO 0, 3, 45, 46) for general-purpose I/O. |
| SR-SYS-015 | The system shall ensure all shared I2C buses have appropriate physical pull-up resistors (2.2kΩ - 4.7kΩ for 3.3V). |
| SR-SYS-016 | The system shall use ADC1 for all analog sensors when Wi-Fi is active (ADC2 is not available with Wi-Fi). |
| SR-SYS-017 | The system shall maintain a canonical GPIO map document as a single source of truth. |

### 3.9 Power & Fault Handling Features (PWR)

| Feature ID | Feature Name | System Requirements |
|------------|--------------|---------------------|
| F-PWR-01 | Brownout Detection and Handling | SR-PWR-001, SR-PWR-002, SR-PWR-003, SR-PWR-004 |
| F-PWR-02 | Power-Loss Recovery | SR-PWR-005, SR-PWR-006, SR-PWR-007, SR-PWR-008 |

**System Requirements Details:**

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

### 3.10 Hardware Abstraction Features (HW)

| Feature ID | Feature Name | System Requirements |
|------------|--------------|---------------------|
| F-HW-01 | Sensor Abstraction Layer (SAL) | SR-HW-001, SR-HW-002, SR-HW-003, SR-HW-004 |
| F-HW-02 | Hardware Interface Abstraction | SR-HW-005, SR-HW-006, SR-HW-007, SR-HW-008 |

**System Requirements Details:**

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

## 4. Summary Statistics

### 4.1 Requirements by Feature Group

| Feature Group | Requirements Count | Percentage |
|---------------|-------------------|------------|
| DAQ | 13 | 9.4% |
| DQC | 18 | 12.9% |
| COM | 17 | 12.2% |
| DIAG | 14 | 10.1% |
| DATA | 13 | 9.4% |
| OTA | 16 | 11.5% |
| SEC | 15 | 10.8% |
| SYS | 17 | 12.2% |
| PWR | 8 | 5.8% |
| HW | 8 | 5.8% |
| **TOTAL** | **139** | **100%** |

### 4.2 New Requirements Added (Version 2.0)

| Feature Group | New Requirements | Requirement IDs |
|---------------|----------------|-----------------|
| DAQ | 4 | SR-DAQ-010, SR-DAQ-011, SR-DAQ-012, SR-DAQ-013 |
| DQC | 3 | SR-DQC-016, SR-DQC-017, SR-DQC-018 |
| COM | 7 | SR-COM-011 through SR-COM-017 |
| DIAG | 3 | SR-DIAG-012, SR-DIAG-013, SR-DIAG-014 |
| DATA | 4 | SR-DATA-010 through SR-DATA-013 |
| OTA | 3 | SR-OTA-014, SR-OTA-015, SR-OTA-016 |
| SEC | 3 | SR-SEC-013, SR-SEC-014, SR-SEC-015 |
| SYS | 4 | SR-SYS-014 through SR-SYS-017 |
| PWR | 8 | SR-PWR-001 through SR-PWR-008 (all new) |
| HW | 8 | SR-HW-001 through SR-HW-008 (all new) |

**Total New Requirements:** 47

## 5. Reverse Traceability (System Requirement → Feature)

This section provides reverse traceability for impact analysis.

| System Requirement | Feature(s) | Feature Group |
|-------------------|------------|---------------|
| SR-DAQ-001 through SR-DAQ-013 | F-DAQ-01, F-DAQ-02, F-DAQ-03, F-DAQ-04 | DAQ |
| SR-DQC-001 through SR-DQC-018 | F-DQC-01, F-DQC-02, F-DQC-03, F-DQC-04, F-DQC-05 | DQC |
| SR-COM-001 through SR-COM-017 | F-COM-01, F-COM-02, F-COM-03, F-COM-04 | COM |
| SR-DIAG-001 through SR-DIAG-014 | F-DIAG-01, F-DIAG-02, F-DIAG-03, F-DIAG-04 | DIAG |
| SR-DATA-001 through SR-DATA-013 | F-DATA-01, F-DATA-02, F-DATA-03, F-DATA-04 | DATA |
| SR-OTA-001 through SR-OTA-016 | F-OTA-01, F-OTA-02, F-OTA-03, F-OTA-04, F-OTA-05 | OTA |
| SR-SEC-001 through SR-SEC-015 | F-SEC-01, F-SEC-02, F-SEC-03, F-SEC-04 | SEC |
| SR-SYS-001 through SR-SYS-017 | F-SYS-01, F-SYS-02, F-SYS-03, F-SYS-04, F-SYS-05 | SYS |
| SR-PWR-001 through SR-PWR-008 | F-PWR-01, F-PWR-02 | PWR |
| SR-HW-001 through SR-HW-008 | F-HW-01, F-HW-02 | HW |

## 6. Document Status

**Status:** Complete  
**Version:** 2.0  
**Date:** 2025-01-19  
**Next Review:** After Component Design Phase

---

**This document provides complete bidirectional traceability between Features and System Requirements for the ASF Sensor Hub.**
