cleanup

2026-01-26 12:49:12 +01:00
parent bedcd373f5
commit ff791564e4
243 changed files with 18986 additions and 0 deletions
--- a/draft/SRS_old/Annex_A_Traceability.md
+++ b/draft/SRS_old/Annex_A_Traceability.md
@@ -0,0 +1,132 @@
+# Annex A: Software Requirements Traceability Matrix
+
+**Document:** SRS Annex A  
+**Version:** 1.0  
+**Date:** 2025-01-19
+
+## Purpose
+
+This annex provides complete traceability between:
+- Features → System Requirements (SR) → Software Requirements (SWR) → Components → Tests
+
+## Traceability Matrix Structure
+
+| Feature ID | System Requirement ID | Software Requirement ID | Component | Test ID |
+|------------|----------------------|------------------------|-----------|---------|
+| F-SYS-01 | SR-SYS-001 | SWR-SYS-001 | STM (State Manager) | T-SYS-001 |
+| F-SYS-01 | SR-SYS-001 | SWR-SYS-002 | STM | T-SYS-002 |
+| F-SYS-01 | SR-SYS-002 | SWR-SYS-003 | STM | T-SYS-003 |
+| F-SYS-01 | SR-SYS-003 | SWR-SYS-004 | STM, Event System | T-SYS-004 |
+| F-SYS-02 | SR-SYS-004 | SWR-SYS-005 | STM | T-SYS-005 |
+| F-SYS-02 | SR-SYS-005 | SWR-SYS-006 | STM, Persistence | T-SYS-006 |
+| F-SYS-02 | SR-SYS-006 | SWR-SYS-007 | STM, Persistence | T-SYS-007 |
+| F-SYS-03 | SR-SYS-007 | SWR-SYS-008 | HMI (OLED Driver) | T-SYS-008 |
+| F-SYS-03 | SR-SYS-008 | SWR-SYS-009 | HMI | T-SYS-009 |
+| F-SYS-03 | SR-SYS-009 | SWR-SYS-010 | HMI | T-SYS-010 |
+| F-SYS-03 | SR-SYS-010 | SWR-SYS-011 | HMI, Diagnostics | T-SYS-011 |
+| F-SYS-04 | SR-SYS-011 | SWR-SYS-012 | Debug Session Manager | T-SYS-012 |
+| F-SYS-04 | SR-SYS-012 | SWR-SYS-013 | Debug Session Manager | T-SYS-013 |
+| F-SYS-04 | SR-SYS-013 | SWR-SYS-014 | Debug Session Manager, Security | T-SYS-014 |
+| F-SYS-04 | SR-SYS-013 | SWR-SYS-015 | Debug Session Manager | T-SYS-015 |
+| F-DAQ-01 | SR-DAQ-001 | SWR-DAQ-001 | Sensor Manager | T-DAQ-001 |
+| F-DAQ-01 | SR-DAQ-002 | SWR-DAQ-002 | Sensor Manager | T-DAQ-002 |
+| F-DAQ-01 | SR-DAQ-003 | SWR-DAQ-003 | Sensor Manager, Sensor Drivers | T-DAQ-003 |
+| F-DAQ-01 | SR-DAQ-004 | SWR-DAQ-004 | Sensor Manager | T-DAQ-004 |
+| F-DAQ-02 | SR-DAQ-005 | SWR-DAQ-005 | Sensor Manager | T-DAQ-005 |
+| F-DAQ-02 | SR-DAQ-006 | SWR-DAQ-006 | Sensor Manager | T-DAQ-006 |
+| F-DAQ-02 | SR-DAQ-007 | SWR-DAQ-007 | Sensor Manager | T-DAQ-007 |
+| F-DAQ-03 | SR-DAQ-008 | SWR-DAQ-008 | Sensor Manager, Time Utils | T-DAQ-008 |
+| F-DAQ-03 | SR-DAQ-009 | SWR-DAQ-009 | Sensor Manager | T-DAQ-009 |
+| F-DAQ-03 | SR-DAQ-010 | SWR-DAQ-010 | Sensor Manager, Data Pool | T-DAQ-010 |
+| F-DQC-01 | SR-DQC-001 | SWR-DQC-001 | Sensor Manager, Sensor Drivers | T-DQC-001 |
+| F-DQC-01 | SR-DQC-002 | SWR-DQC-002 | Sensor Manager | T-DQC-002 |
+| F-DQC-01 | SR-DQC-003 | SWR-DQC-003 | Sensor Manager | T-DQC-003 |
+| F-DQC-02 | SR-DQC-004 | SWR-DQC-004 | Sensor Manager | T-DQC-004 |
+| F-DQC-02 | SR-DQC-005 | SWR-DQC-005 | Sensor Manager | T-DQC-005 |
+| F-DQC-02 | SR-DQC-006 | SWR-DQC-006 | Sensor Manager, Diagnostics | T-DQC-006 |
+| F-DQC-03 | SR-DQC-007 | SWR-DQC-007 | Sensor Manager | T-DQC-007 |
+| F-DQC-03 | SR-DQC-008 | SWR-DQC-008 | Sensor Manager | T-DQC-008 |
+| F-DQC-03 | SR-DQC-009 | SWR-DQC-009 | Sensor Manager | T-DQC-009 |
+| F-DQC-03 | SR-DQC-010 | SWR-DQC-010 | Sensor Manager, Communication | T-DQC-010 |
+| F-DQC-04 | SR-DQC-011 | SWR-DQC-011 | Machine Constant Manager | T-DQC-011 |
+| F-DQC-04 | SR-DQC-012 | SWR-DQC-012 | Machine Constant Manager, Persistence | T-DQC-012 |
+| F-DQC-04 | SR-DQC-013 | SWR-DQC-013 | Machine Constant Manager | T-DQC-013 |
+| F-DQC-04 | SR-DQC-014 | SWR-DQC-014 | Machine Constant Manager, Communication | T-DQC-014 |
+| F-DQC-04 | SR-DQC-015 | SWR-DQC-015 | Machine Constant Manager, STM | T-DQC-015 |
+| F-COM-01 | SR-COM-001 | SWR-COM-001 | Main Hub APIs, Network Stack | T-COM-001 |
+| F-COM-01 | SR-COM-002 | SWR-COM-002 | Main Hub APIs | T-COM-002 |
+| F-COM-01 | SR-COM-003 | SWR-COM-003 | Main Hub APIs | T-COM-003 |
+| F-COM-01 | SR-COM-004 | SWR-COM-004 | Network Stack | T-COM-004 |
+| F-COM-02 | SR-COM-005 | SWR-COM-005 | Main Hub APIs | T-COM-005 |
+| F-COM-02 | SR-COM-006 | SWR-COM-006 | Main Hub APIs, Data Pool | T-COM-006 |
+| F-COM-02 | SR-COM-007 | SWR-COM-007 | Main Hub APIs | T-COM-007 |
+| F-COM-03 | SR-COM-008 | SWR-COM-008 | Network Stack | T-COM-008 |
+| F-COM-03 | SR-COM-009 | SWR-COM-009 | Network Stack | T-COM-009 |
+| F-COM-03 | SR-COM-010 | SWR-COM-009 | Network Stack | T-COM-010 |
+| F-DIAG-01 | SR-DIAG-001 | SWR-DIAG-001 | Diagnostics Task | T-DIAG-001 |
+| F-DIAG-01 | SR-DIAG-002 | SWR-DIAG-002 | Diagnostics Task | T-DIAG-002 |
+| F-DIAG-01 | SR-DIAG-003 | SWR-DIAG-003 | Diagnostics Task | T-DIAG-003 |
+| F-DIAG-01 | SR-DIAG-004 | SWR-DIAG-004 | Diagnostics Task | T-DIAG-004 |
+| F-DIAG-02 | SR-DIAG-005 | SWR-DIAG-005 | Diagnostics Task, Persistence | T-DIAG-005 |
+| F-DIAG-02 | SR-DIAG-006 | SWR-DIAG-006 | Diagnostics Task, Persistence | T-DIAG-006 |
+| F-DIAG-02 | SR-DIAG-007 | SWR-DIAG-007 | Diagnostics Task, Persistence | T-DIAG-007 |
+| F-DIAG-03 | SR-DIAG-008 | SWR-DIAG-008 | Diagnostics Task | T-DIAG-008 |
+| F-DIAG-03 | SR-DIAG-009 | SWR-DIAG-009 | Diagnostics Task | T-DIAG-009 |
+| F-DIAG-03 | SR-DIAG-010 | SWR-DIAG-010 | Diagnostics Task | T-DIAG-010 |
+| F-DIAG-03 | SR-DIAG-011 | SWR-DIAG-011 | Diagnostics Task | T-DIAG-011 |
+| F-DATA-01 | SR-DATA-001 | SWR-DATA-001 | Persistence | T-DATA-001 |
+| F-DATA-01 | SR-DATA-002 | SWR-DATA-002 | Persistence | T-DATA-002 |
+| F-DATA-01 | SR-DATA-003 | SWR-DATA-003 | Persistence | T-DATA-003 |
+| F-DATA-02 | SR-DATA-004 | SWR-DATA-004 | Persistence | T-DATA-004 |
+| F-DATA-02 | SR-DATA-005 | SWR-DATA-005 | Persistence | T-DATA-005 |
+| F-DATA-02 | SR-DATA-006 | SWR-DATA-006 | Persistence | T-DATA-006 |
+| F-DATA-03 | SR-DATA-007 | SWR-DATA-007 | Persistence, STM | T-DATA-007 |
+| F-DATA-03 | SR-DATA-008 | SWR-DATA-008 | Persistence, OTA Manager | T-DATA-008 |
+| F-DATA-03 | SR-DATA-009 | SWR-DATA-009 | Persistence, STM | T-DATA-009 |
+| F-OTA-01 | SR-OTA-001 | SWR-OTA-001 | OTA Manager | T-OTA-001 |
+| F-OTA-01 | SR-OTA-002 | SWR-OTA-002 | OTA Manager | T-OTA-002 |
+| F-OTA-01 | SR-OTA-003 | SWR-OTA-003 | OTA Manager | T-OTA-003 |
+| F-OTA-02 | SR-OTA-004 | SWR-OTA-004 | OTA Manager, Network Stack | T-OTA-004 |
+| F-OTA-02 | SR-OTA-005 | SWR-OTA-005 | OTA Manager, Persistence | T-OTA-005 |
+| F-OTA-02 | SR-OTA-006 | SWR-OTA-006 | OTA Manager | T-OTA-006 |
+| F-OTA-03 | SR-OTA-007 | SWR-OTA-007 | OTA Manager, Security | T-OTA-007 |
+| F-OTA-03 | SR-OTA-008 | SWR-OTA-008 | OTA Manager | T-OTA-008 |
+| F-OTA-03 | SR-OTA-009 | SWR-OTA-009 | OTA Manager, Communication | T-OTA-009 |
+| F-OTA-04 | SR-OTA-010 | SWR-OTA-010 | OTA Manager, STM | T-OTA-010 |
+| F-OTA-04 | SR-OTA-011 | SWR-OTA-011 | OTA Manager, Persistence | T-OTA-011 |
+| F-OTA-04 | SR-OTA-012 | SWR-OTA-012 | OTA Manager | T-OTA-012 |
+| F-OTA-04 | SR-OTA-013 | SWR-OTA-013 | OTA Manager | T-OTA-013 |
+| F-SEC-01 | SR-SEC-001 | SWR-SEC-001 | Security (Secure Boot) | T-SEC-001 |
+| F-SEC-01 | SR-SEC-002 | SWR-SEC-002 | Security (Secure Boot) | T-SEC-002 |
+| F-SEC-01 | SR-SEC-003 | SWR-SEC-003 | Security (Secure Boot), STM | T-SEC-003 |
+| F-SEC-01 | SR-SEC-004 | SWR-SEC-004 | Security (Secure Boot) | T-SEC-004 |
+| F-SEC-02 | SR-SEC-005 | SWR-SEC-005 | Security (Flash Encryption) | T-SEC-005 |
+| F-SEC-02 | SR-SEC-006 | SWR-SEC-006 | Security (Flash Encryption), Persistence | T-SEC-006 |
+| F-SEC-02 | SR-SEC-007 | SWR-SEC-007 | Security (Key Management) | T-SEC-007 |
+| F-SEC-02 | SR-SEC-008 | SWR-SEC-008 | Security (Data Integrity) | T-SEC-008 |
+| F-SEC-03 | SR-SEC-009 | SWR-SEC-009 | Security (Communication Encryption) | T-SEC-009 |
+| F-SEC-03 | SR-SEC-010 | SWR-SEC-010 | Security (Message Integrity) | T-SEC-010 |
+| F-SEC-03 | SR-SEC-011 | SWR-SEC-011 | Security (OTA Encryption) | T-SEC-011 |
+| F-SEC-03 | SR-SEC-012 | SWR-SEC-012 | Security, Diagnostics | T-SEC-012 |
+
+## Component Abbreviations
+
+- **STM:** State Manager (System Management)
+- **HMI:** Human-Machine Interface (OLED + Buttons)
+- **Sensor Manager:** Sensor acquisition and management
+- **Machine Constant Manager:** Machine constants management
+- **Main Hub APIs:** Main Hub communication interface
+- **Network Stack:** Low-level network communication
+- **Diagnostics Task:** Diagnostics and health monitoring
+- **Error Handler:** Fault classification and escalation
+- **Persistence:** Data Persistence component
+- **OTA Manager:** Firmware update management
+- **Security:** Security and safety features
+- **Event System:** Cross-component event communication
+- **Data Pool:** Runtime data storage
+
+## Notes
+
+- Test IDs (T-*) are placeholders for future test specification
+- Component assignments are preliminary and may be refined during detailed design
+- Some SWRs may map to multiple components (e.g., SWR-SYS-004 requires STM and Event System)
--- a/draft/SRS_old/Annex_B_Interfaces.md
+++ b/draft/SRS_old/Annex_B_Interfaces.md
@@ -0,0 +1,236 @@
+# Annex B: External Interface Specifications
+
+**Document:** SRS Annex B  
+**Version:** 1.0  
+**Date:** 2025-01-19
+
+## Purpose
+
+This annex defines the external interfaces between the Sensor Hub and external entities (Main Hub, sensors, storage, HMI).
+
+## 1. Main Hub Communication Interface
+
+### 1.1 Protocol Stack
+
+```
+Application Layer (Sensor Hub APIs)
+    ↓
+Transport Security Layer (TLS/DTLS)
+    ↓
+Network Layer (Wi-Fi / Zigbee / LoRa)
+    ↓
+Physical Layer
+```
+
+### 1.2 Message Format
+
+**Request Message Structure:**
+```c
+typedef struct {
+    uint8_t message_type;      // REQ_DATA, REQ_STATUS, REQ_DIAG, CMD_CONFIG, CMD_OTA
+    uint16_t message_id;       // Unique request ID
+    uint32_t timestamp;        // Request timestamp
+    uint16_t payload_length;   // Payload length in bytes
+    uint8_t payload[];         // Message-specific payload
+    uint32_t checksum;         // Message integrity checksum
+} main_hub_request_t;
+```
+
+**Response Message Structure:**
+```c
+typedef struct {
+    uint8_t message_type;      // RESP_DATA, RESP_STATUS, RESP_DIAG, ACK, NACK
+    uint16_t message_id;       // Matching request ID
+    uint8_t status_code;        // SUCCESS, ERROR, TIMEOUT
+    uint32_t timestamp;        // Response timestamp
+    uint16_t payload_length;   // Payload length in bytes
+    uint8_t payload[];         // Message-specific payload
+    uint32_t checksum;         // Message integrity checksum
+} main_hub_response_t;
+```
+
+### 1.3 Message Types
+
+| Message Type | Direction | Purpose | Payload |
+|--------------|-----------|---------|---------|
+| `REQ_DATA` | Main Hub → Sensor Hub | Request latest sensor data | None |
+| `RESP_DATA` | Sensor Hub → Main Hub | Sensor data response | Sensor data records |
+| `REQ_STATUS` | Main Hub → Sensor Hub | Request system status | None |
+| `RESP_STATUS` | Sensor Hub → Main Hub | System status response | Status information |
+| `REQ_DIAG` | Main Hub → Sensor Hub | Request diagnostic data | Diagnostic filter |
+| `RESP_DIAG` | Sensor Hub → Main Hub | Diagnostic data response | Diagnostic events |
+| `CMD_CONFIG` | Main Hub → Sensor Hub | Configuration update | Configuration data |
+| `CMD_OTA` | Main Hub → Sensor Hub | OTA update request | OTA metadata |
+| `ACK` | Sensor Hub → Main Hub | Acknowledgment | None or status |
+| `NACK` | Sensor Hub → Main Hub | Negative acknowledgment | Error code |
+
+### 1.4 Communication Requirements
+
+- **Encryption:** All messages SHALL be encrypted using TLS/DTLS
+- **Authentication:** All messages SHALL be authenticated
+- **Integrity:** All messages SHALL include integrity checksums
+- **Timeout:** Request timeout: 5 seconds
+- **Retry:** Maximum 3 retries with exponential backoff
+
+## 2. Sensor Interfaces
+
+### 2.1 Supported Protocols
+
+| Protocol | Sensor Types | Interface |
+|----------|--------------|-----------|
+| I2C | Temperature, Humidity, CO2, NH3, VOC, Light | I2C bus (configurable pins) |
+| SPI | Particulate matter sensors | SPI bus (configurable pins) |
+| UART | Some sensor modules | UART (configurable pins) |
+| Analog | Analog sensors | ADC channels |
+
+### 2.2 Sensor Detection Signal
+
+Each sensor slot SHALL provide a dedicated GPIO pin for presence detection:
+- **High (3.3V):** Sensor present
+- **Low (0V):** Sensor absent
+
+### 2.3 Sensor Data Format
+
+```c
+typedef struct {
+    uint8_t sensor_id;          // Unique sensor identifier
+    uint8_t sensor_type;        // TEMP, HUM, CO2, NH3, VOC, PM, LIGHT
+    float value;                // Filtered sensor value
+    uint8_t unit;               // Unit code (C, RH, PPM, LUX, etc.)
+    uint64_t timestamp_us;     // Timestamp in microseconds
+    uint8_t validity_status;    // VALID, INVALID, DEGRADED, FAILED
+    uint8_t sample_count;       // Number of samples used for filtering
+} sensor_data_record_t;
+```
+
+## 3. Storage Interfaces
+
+### 3.1 SD Card Interface
+
+**File System:** FAT32  
+**Mount Point:** `/sdcard`
+
+**Directory Structure:**
+```
+/sdcard/
+  ├── sensor_data/
+  │   └── YYYYMMDD_HHMMSS.dat
+  ├── diagnostics/
+  │   └── diag_log.dat
+  ├── machine_constants/
+  │   └── mc.dat
+  └── ota/
+      └── firmware.bin
+```
+
+**File Naming Convention:**
+- Sensor data: `YYYYMMDD_HHMMSS.dat` (timestamp-based)
+- Diagnostics: `diag_log.dat` (circular log)
+- Machine constants: `mc.dat` (single file)
+- OTA firmware: `firmware.bin` (temporary)
+
+### 3.2 NVM (Non-Volatile Memory) Interface
+
+**Storage Areas:**
+- **Machine Constants:** 4KB
+- **System Configuration:** 2KB
+- **Diagnostic Log (circular):** 8KB
+- **OTA Metadata:** 1KB
+
+**Access Method:** ESP-IDF NVS (Non-Volatile Storage) API
+
+## 4. HMI Interfaces
+
+### 4.1 OLED Display Interface
+
+**Protocol:** I2C  
+**Address:** Configurable (default: 0x3C)  
+**Display:** 128x64 pixels, monochrome
+
+**Display Content:**
+- **Main Screen:** Connectivity, System State, Sensor Count, Time/Date
+- **Menu Screens:** Diagnostics, Sensors, Health
+
+### 4.2 Button Interface
+
+**Buttons:** 3 GPIO inputs (Up, Down, Select)
+
+**Button Behavior:**
+- **Up:** Navigate menu up / Scroll up
+- **Down:** Navigate menu down / Scroll down
+- **Select:** Enter menu / Select item / Return to main screen
+
+**Debouncing:** Hardware debouncing (10ms) + software debouncing (50ms)
+
+## 5. Debug Interface
+
+### 5.1 Physical Interface
+
+**Protocol:** UART  
+**Baud Rate:** 115200  
+**Data Bits:** 8  
+**Parity:** None  
+**Stop Bits:** 1  
+**Flow Control:** None
+
+### 5.2 Debug Protocol
+
+**Session Establishment:**
+1. Client sends authentication challenge
+2. Sensor Hub responds with challenge response
+3. Client sends session key (encrypted)
+4. Sensor Hub validates and establishes session
+
+**Debug Commands:**
+- `READ_DIAG <filter>` - Read diagnostic events
+- `READ_STATUS` - Read system status
+- `READ_MC` - Read machine constants
+- `CLEAR_DIAG` - Clear diagnostic log
+- `REBOOT` - Reboot system
+- `TEARDOWN` - Initiate controlled teardown
+
+**Security:** All debug sessions SHALL be authenticated. Unauthorized access SHALL be rejected and logged as a security violation.
+
+## 6. Peer Sensor Hub Communication
+
+### 6.1 Protocol
+
+**Protocol:** Same as Main Hub communication (Wi-Fi / Zigbee / LoRa)  
+**Message Types:** Limited to connectivity checks and time synchronization
+
+### 6.2 Message Types
+
+| Message Type | Purpose |
+|--------------|---------|
+| `PEER_PING` | Connectivity check |
+| `PEER_PONG` | Connectivity response |
+| `PEER_TIME_SYNC` | Time synchronization request |
+| `PEER_TIME_RESP` | Time synchronization response |
+
+### 6.3 Requirements
+
+- Peer communication SHALL NOT interfere with Main Hub communication
+- Peer communication SHALL be encrypted and authenticated
+- Peer communication SHALL be limited to coordination functions only
+
+## 7. Interface Requirements Summary
+
+| Interface | Protocol | Encryption | Authentication | Integrity |
+|-----------|----------|------------|----------------|-----------|
+| Main Hub | TLS/DTLS over Wi-Fi/Zigbee/LoRa | Yes | Yes | Yes |
+| Sensors | I2C/SPI/UART/Analog | No | No | No (hardware-level) |
+| SD Card | SPI (SD protocol) | Optional (SWR-SEC-006) | No | Yes (file system) |
+| NVM | ESP-IDF NVS | Optional (SWR-SEC-005) | No | Yes (NVS) |
+| OLED Display | I2C | No | No | No |
+| Buttons | GPIO | No | No | No |
+| Debug | UART | Yes | Yes | Yes |
+| Peer Sensor Hub | Same as Main Hub | Yes | Yes | Yes |
+
+## 8. Traceability
+
+- **SWR-IF-001:** Main Hub communication interface
+- **SWR-IF-002:** Sensor interfaces
+- **SWR-IF-003:** OLED display interface
+- **SWR-IF-004:** Button input interfaces
+- **SWR-IF-005:** Storage interfaces
+- **SWR-IF-006:** Debug interface
--- a/draft/SRS_old/Annex_C_Budgets.md
+++ b/draft/SRS_old/Annex_C_Budgets.md
@@ -0,0 +1,230 @@
+# Annex C: Timing and Resource Budgets
+
+**Document:** SRS Annex C  
+**Version:** 1.0  
+**Date:** 2025-01-19
+
+## Purpose
+
+This annex defines timing budgets, resource allocation limits, and performance constraints for the Sensor Hub software.
+
+## 1. Timing Budgets
+
+### 1.1 Sensor Acquisition Timing
+
+| Operation | Maximum Duration | Justification |
+|-----------|------------------|---------------|
+| Single sensor sample (I2C) | 10ms | I2C transaction time |
+| Single sensor sample (SPI) | 5ms | SPI transaction time |
+| Single sensor sample (UART) | 20ms | UART transaction time |
+| Single sensor sample (Analog/ADC) | 1ms | ADC conversion time |
+| Filtering (10 samples) | 5ms | Local filtering computation |
+| Timestamp generation | 1ms | System time access |
+| Complete acquisition cycle (per sensor) | 100ms | Total per sensor (worst case) |
+| Complete acquisition cycle (all sensors) | 500ms | 5 sensors × 100ms (with overlap) |
+
+### 1.2 State Transition Timing
+
+| Transition | Maximum Duration | Justification |
+|------------|------------------|---------------|
+| `[*]` → `INIT` | 100ms | Power-on initialization |
+| `INIT` → `RUNNING` | 5s | Hardware init, secure boot, MC load |
+| `INIT` → `BOOT_FAILURE` | 2s | Secure boot verification |
+| `RUNNING` → `WARNING` | 50ms | Fault detection and state change |
+| `RUNNING` → `FAULT` | 50ms | Critical fault detection |
+| `RUNNING` → `OTA_PREP` | 100ms | OTA request processing |
+| `OTA_PREP` → `TEARDOWN` | 2s | Readiness validation |
+| `TEARDOWN` → `OTA_UPDATE` | 500ms | Data flush and resource release |
+| `TEARDOWN` → `INIT` | 500ms | Data flush and reset |
+| `OTA_UPDATE` → `RUNNING` | 10 minutes | Firmware transfer and flashing |
+| `RUNNING` → `SERVICE` | 100ms | Debug session establishment |
+| `SERVICE` → `RUNNING` | 50ms | Debug session closure |
+| `RUNNING` → `SD_DEGRADED` | 200ms | SD failure detection |
+
+### 1.3 Communication Timing
+
+| Operation | Maximum Duration | Justification |
+|------------|------------------|---------------|
+| Main Hub request processing | 100ms | Data retrieval and response |
+| Main Hub message transmission | 50ms | Network transmission (local) |
+| Main Hub message reception | 50ms | Network reception (local) |
+| Communication link failure detection | 30s | Heartbeat timeout |
+| OTA firmware chunk reception | 1s | Network transfer per chunk |
+| Peer Sensor Hub ping | 100ms | Connectivity check |
+
+### 1.4 Persistence Timing
+
+| Operation | Maximum Duration | Justification |
+|------------|------------------|---------------|
+| Sensor data write (SD card) | 50ms | File write operation |
+| Diagnostic event write (SD card) | 20ms | Log append operation |
+| Machine constants write (NVM) | 10ms | NVS write operation |
+| Data flush (all pending) | 200ms | Complete flush operation |
+| SD card failure detection | 500ms | File system check |
+
+### 1.5 OTA Timing
+
+| Operation | Maximum Duration | Justification |
+|------------|------------------|---------------|
+| OTA readiness validation | 2s | System state and resource check |
+| Firmware chunk reception | 1s | Network transfer per chunk |
+| Firmware integrity validation | 5s | Cryptographic verification |
+| Firmware flashing | 2 minutes | Flash write operation |
+| Complete OTA operation | 10 minutes | End-to-end OTA process |
+
+### 1.6 Diagnostic Timing
+
+| Operation | Maximum Duration | Justification |
+|------------|------------------|---------------|
+| Diagnostic event generation | 1ms | Event creation and classification |
+| Diagnostic event persistence | 20ms | Log write operation |
+| Diagnostic query processing | 50ms | Log read and filtering |
+| Fault escalation | 50ms | Severity check and state transition |
+
+## 2. Resource Budgets
+
+### 2.1 Memory (RAM) Budget
+
+| Component | Allocation | Peak Usage | Monitoring Required |
+|-----------|------------|------------|---------------------|
+| System (RTOS, ESP-IDF) | 80KB | 100KB | Yes |
+| Sensor Manager | 20KB | 25KB | Yes |
+| Event System | 10KB | 15KB | Yes |
+| Data Pool | 15KB | 20KB | Yes |
+| Communication Stack | 30KB | 40KB | Yes |
+| Diagnostics | 10KB | 15KB | Yes |
+| Persistence | 15KB | 20KB | Yes |
+| OTA Manager | 20KB | 30KB | Yes |
+| Security | 10KB | 15KB | Yes |
+| System Management | 10KB | 15KB | Yes |
+| HMI | 5KB | 8KB | Yes |
+| **Total Allocated** | **225KB** | **283KB** | |
+| **Available (ESP32-S3)** | **512KB** | **512KB** | |
+| **Utilization** | **44%** | **55%** | |
+| **Safety Margin** | **56%** | **45%** | |
+
+**Note:** Peak usage includes worst-case stack usage and temporary buffers. Actual runtime usage SHALL be monitored and maintained below 60% (307KB).
+
+### 2.2 Flash (Program Memory) Budget
+
+| Component | Allocation | Notes |
+|-----------|------------|-------|
+| Bootloader | 32KB | ESP-IDF bootloader |
+| Application Code | 1.5MB | Main application firmware |
+| OTA Partition 0 | 1.5MB | Primary firmware partition |
+| OTA Partition 1 | 1.5MB | Secondary firmware partition (for updates) |
+| NVS (Non-Volatile Storage) | 20KB | Configuration and MC storage |
+| SPIFFS/LittleFS | 500KB | File system (if used) |
+| **Total Used** | **5.052MB** | |
+| **Available (8MB Flash)** | **8MB** | |
+| **Utilization** | **63%** | |
+| **Safety Margin** | **37%** | |
+
+### 2.3 CPU Utilization Budget
+
+| Task | Priority | CPU Usage (Normal) | CPU Usage (Peak) | Notes |
+|------|----------|-------------------|------------------|-------|
+| Sensor Acquisition | High | 15% | 25% | Time-critical |
+| Communication | Medium | 10% | 20% | Network I/O |
+| Diagnostics | Low | 5% | 10% | Background |
+| Persistence | Medium | 5% | 15% | Storage I/O |
+| System Management | High | 5% | 10% | State management |
+| HMI | Low | 2% | 5% | Display updates |
+| Idle | - | 58% | 15% | System idle |
+| **Total** | - | **100%** | **100%** | |
+
+**Requirement:** CPU utilization SHALL NOT exceed 80% during normal operation (SWR-PERF-005).
+
+### 2.4 Storage (SD Card) Budget
+
+| Data Type | Daily Write Volume | Retention Policy | Notes |
+|-----------|-------------------|------------------|-------|
+| Sensor Data | 50MB | 7 days (rolling) | 5 sensors × 1 sample/min × 24h |
+| Diagnostic Log | 5MB | 30 days (circular) | Bounded log with overwrite |
+| Machine Constants | 1KB | Permanent | Updated only on configuration change |
+| OTA Firmware | 2MB | Temporary | Deleted after successful update |
+| **Total Daily Writes** | **57MB** | | |
+| **SD Card Capacity** | **32GB** (typical) | | |
+| **Wear Level** | **Low** | | With wear-leveling |
+
+**Requirement:** SD card writes SHALL be wear-aware to prevent premature failure (SWR-DATA-013).
+
+### 2.5 Network Bandwidth Budget
+
+| Operation | Bandwidth | Frequency | Daily Volume |
+|-----------|-----------|-----------|--------------|
+| Sensor Data Transmission | 1KB/packet | 1 packet/min | 1.44MB/day |
+| Diagnostic Reporting | 500B/packet | On-demand | Variable |
+| Status Updates | 200B/packet | 1 packet/5min | 57.6KB/day |
+| OTA Firmware Transfer | 2MB | On-demand | Variable |
+| **Total (Normal Operation)** | - | - | **~1.5MB/day** | |
+
+**Note:** OTA transfers are infrequent and excluded from daily normal operation budget.
+
+## 3. Performance Constraints
+
+### 3.1 Real-Time Constraints
+
+| Constraint | Requirement | Verification Method |
+|------------|-------------|---------------------|
+| Sensor acquisition determinism | ≤ 100ms per sensor | Timing measurement |
+| State transition determinism | ≤ 50ms (except INIT, TEARDOWN) | Timing measurement |
+| Communication response time | ≤ 100ms | End-to-end timing |
+| Data persistence latency | ≤ 200ms | Write operation timing |
+
+### 3.2 Resource Constraints
+
+| Resource | Limit | Monitoring | Action on Exceed |
+|----------|-------|------------|------------------|
+| RAM Usage | 60% (307KB) | Runtime monitoring | Enter WARNING state, reduce buffers |
+| CPU Usage | 80% | Runtime monitoring | Reduce task priorities, throttle operations |
+| SD Card Space | 10% free | File system check | Trigger data retention policy |
+| Flash Usage | 70% (5.6MB) | Build-time check | Optimize code size |
+
+### 3.3 Quality Constraints
+
+| Constraint | Requirement | Verification Method |
+|------------|-------------|---------------------|
+| Power loss recovery | < 1 second | Power interruption test |
+| SD card failure handling | Graceful degradation | SD card removal test |
+| OTA failure recovery | Rollback capability | OTA failure injection test |
+| Secure boot failure | BOOT_FAILURE state | Secure boot verification test |
+
+## 4. Worst-Case Execution Time (WCET) Analysis
+
+### 4.1 Critical Paths
+
+**Sensor Acquisition Path:**
+```
+Sensor Read (10ms) × 10 samples = 100ms
+ Filtering (5ms) = 105ms
+ Timestamp (1ms) = 106ms
+WCET = 110ms (with 4ms margin)
+```
+
+**State Transition Path:**
+```
+State validation (5ms)
+ Component notification (10ms)
+ State update (1ms)
+WCET = 20ms (with 30ms margin for 50ms requirement)
+```
+
+**Data Persistence Path:**
+```
+Data serialization (10ms)
+ File write (50ms)
+ Verification (10ms)
+WCET = 80ms (with 120ms margin for 200ms requirement)
+```
+
+## 5. Traceability
+
+- **SWR-PERF-001:** Sensor acquisition cycle timing
+- **SWR-PERF-002:** State transition timing
+- **SWR-PERF-003:** Data persistence timing
+- **SWR-PERF-004:** OTA operation duration
+- **SWR-PERF-005:** CPU utilization limit
+- **SWR-PERF-006:** RAM usage limit
+- **SWR-PERF-007:** Main Hub response time
+- **SWR-PERF-008:** Communication link failure detection
--- a/draft/SRS_old/SRS.md
+++ b/draft/SRS_old/SRS.md
@@ -0,0 +1,844 @@
+# Software Requirements Specification (SRS)
+
+**Document ID:** SRS-ASF-SensorHub-001  
+**Version:** 1.0  
+**Date:** 2025-01-19  
+**Standard:** ISO/IEC/IEEE 29148:2018  
+**Scope:** Sensor Hub (Sub-Hub) Software Requirements
+
+## 1. Introduction
+
+### 1.1 Purpose
+
+This Software Requirements Specification (SRS) defines the software requirements for the ASF Sensor Hub (Sub-Hub) embedded system. This document provides a complete description of all software requirements, derived from system requirements and features, to enable implementation and verification.
+
+### 1.2 Scope
+
+This SRS covers:
+- Sensor Hub firmware running on ESP32-S3
+- All application-layer components and drivers
+- Interfaces to Main Hub, sensors, and storage
+- System state management, diagnostics, and security
+
+This SRS explicitly excludes:
+- Main Hub firmware
+- Cloud services
+- Hardware design specifications
+- Manufacturing and deployment procedures
+
+### 1.3 Definitions, Acronyms, and Abbreviations
+
+| Term | Definition |
+|------|------------|
+| **DAQ** | Data Acquisition |
+| **DQC** | Data Quality & Calibration |
+| **DIAG** | Diagnostics & Health Monitoring |
+| **DP** | Data Persistence component |
+| **FSM** | Finite State Machine |
+| **MC** | Machine Constants |
+| **NVM** | Non-Volatile Memory |
+| **OTA** | Over-The-Air (firmware update) |
+| **SRS** | Software Requirements Specification |
+| **SR** | System Requirement |
+| **SWR** | Software Requirement |
+| **SWRS** | Software Requirements |
+
+### 1.4 References
+
+- ISO/IEC/IEEE 29148:2018 - Systems and software engineering - Life cycle processes - Requirements engineering
+- System Requirements: `System Design/system_requirementsand_and_traceability.csv`
+- Features: `System Design/Features/`
+- System State Machine: `System Design/System_State_Machine_Specification.md`
+- Failure Handling Model: `System Design/Failure_Handling_Model.md`
+- Cross-Feature Constraints: `System Design/Features/Cross-Feature Constraints.md`
+
+### 1.5 Overview
+
+This SRS is organized as follows:
+- **Section 2:** Overall Description (product perspective, functions, user characteristics, constraints)
+- **Section 3:** Specific Requirements (functional, interface, performance, design constraints, quality attributes)
+- **Annex A:** Software Requirements Traceability Matrix
+- **Annex B:** External Interface Specifications
+- **Annex C:** Timing and Resource Budgets
+
+## 2. Overall Description
+
+### 2.1 Product Perspective
+
+The Sensor Hub is an embedded system component within the Distributed Intelligent Poultry Farm Environmental Control System (DIPFECS). It operates autonomously but communicates with a Main Hub for data transmission and configuration updates.
+
+**System Context:**
+```
+[Sensors] → [Sensor Hub] ↔ [Main Hub] ↔ [Central Server]
+                ↓
+           [SD Card / NVM]
+```
+
+### 2.2 Product Functions
+
+The Sensor Hub software provides the following major functions:
+
+1. **Sensor Data Acquisition (DAQ)** - Multi-sensor sampling, filtering, timestamping
+2. **Data Quality & Calibration (DQC)** - Sensor detection, validation, calibration management
+3. **Communication (COM)** - Bidirectional communication with Main Hub and peer Sensor Hubs
+4. **Diagnostics & Health Monitoring (DIAG)** - Fault detection, classification, persistent logging
+5. **Persistence & Data Management (DATA)** - Non-volatile storage of sensor data and system state
+6. **Firmware Update (OTA)** - Secure over-the-air firmware updates
+7. **Security & Safety (SEC)** - Secure boot, encrypted storage, encrypted communication
+8. **System Management (SYS)** - State machine, teardown, HMI, debug sessions
+
+### 2.3 User Characteristics
+
+**Primary Users:**
+- **Farm Operators:** Monitor system status via OLED display
+- **Engineers:** Access diagnostic and debug sessions
+- **Main Hub:** Automated data collection and control
+
+**User Assumptions:**
+- Farm operators have basic technical knowledge
+- Engineers have embedded systems expertise
+- Main Hub communication is automated
+
+### 2.4 Constraints
+
+#### 2.4.1 Hardware Constraints
+- ESP32-S3 microcontroller (dual-core, 512KB SRAM, 8MB flash)
+- Limited I/O pins for sensors and peripherals
+- SD card for external storage (subject to wear and failure)
+- Power: Continuous AC power (with brief interruptions)
+
+#### 2.4.2 Software Constraints
+- ESP-IDF v5.4 framework
+- FreeRTOS for task scheduling
+- C/C++ programming languages
+- No dynamic memory allocation in critical paths
+
+#### 2.4.3 Regulatory Constraints
+- Animal welfare regulations compliance
+- Environmental monitoring standards
+- Security requirements (encryption, authentication)
+
+#### 2.4.4 Operational Constraints
+- Harsh environment (humidity, dust, ammonia)
+- Unattended operation (24/7)
+- Remote deployment (limited physical access)
+
+### 2.5 Assumptions and Dependencies
+
+**Assumptions:**
+- Sensors are pre-configured and compatible
+- Main Hub provides time synchronization
+- Cryptographic keys are securely provisioned
+- Power interruptions are brief (< 1 second)
+
+**Dependencies:**
+- ESP-IDF framework availability and stability
+- Sensor driver availability
+- Main Hub communication protocol compatibility
+
+## 3. Specific Requirements
+
+### 3.1 Functional Requirements
+
+#### 3.1.1 System State Management (SWR-SYS-001 through SWR-SYS-015)
+
+**SWR-SYS-001:** The software SHALL implement a finite state machine (FSM) with the following states: INIT, BOOT_FAILURE, RUNNING, WARNING, FAULT, OTA_PREP, OTA_UPDATE, MC_UPDATE, TEARDOWN, SERVICE, SD_DEGRADED.
+
+**Traceability:** SR-SYS-001
+
+**SWR-SYS-002:** The software SHALL enforce valid state transitions as defined in the System State Machine Specification.
+
+**Traceability:** SR-SYS-001
+
+**SWR-SYS-003:** The software SHALL restrict feature operations based on the current system state according to per-state execution rules.
+
+**Traceability:** SR-SYS-002
+
+**SWR-SYS-004:** The software SHALL notify all registered components when a state transition occurs via the Event System.
+
+**Traceability:** SR-SYS-003
+
+**SWR-SYS-005:** The software SHALL execute a controlled teardown sequence before firmware updates, machine constant updates, or system resets.
+
+**Traceability:** SR-SYS-004
+
+**SWR-SYS-006:** The software SHALL persist all critical runtime data before completing a teardown sequence.
+
+**Traceability:** SR-SYS-005
+
+**SWR-SYS-007:** The software SHALL prevent data corruption during teardown and reset operations.
+
+**Traceability:** SR-SYS-006
+
+**SWR-SYS-008:** The software SHALL provide a local OLED display interface using I2C communication protocol.
+
+**Traceability:** SR-SYS-007
+
+**SWR-SYS-009:** The software SHALL display connectivity status, system state, connected sensor summary, and time/date on the OLED display.
+
+**Traceability:** SR-SYS-008
+
+**SWR-SYS-010:** The software SHALL provide menu navigation using Up, Down, and Select buttons.
+
+**Traceability:** SR-SYS-009
+
+**SWR-SYS-011:** The software SHALL provide diagnostic, sensor, and health information through the local OLED menu interface.
+
+**Traceability:** SR-SYS-010
+
+**SWR-SYS-012:** The software SHALL support diagnostic sessions for retrieving system status and diagnostic data.
+
+**Traceability:** SR-SYS-011
+
+**SWR-SYS-013:** The software SHALL support debug sessions allowing controlled engineering commands.
+
+**Traceability:** SR-SYS-012
+
+**SWR-SYS-014:** The software SHALL restrict debug session actions to authorized engineering access only.
+
+**Traceability:** SR-SYS-013
+
+**SWR-SYS-015:** The software SHALL ensure debug sessions do not interfere with normal sensor acquisition or communication operations.
+
+**Traceability:** SR-SYS-013, CFC-DBG-01
+
+#### 3.1.2 Sensor Data Acquisition (SWR-DAQ-001 through SWR-DAQ-015)
+
+**SWR-DAQ-001:** The software SHALL support simultaneous acquisition of environmental data from multiple sensor types (temperature, humidity, CO2, NH3, VOC, particulate matter, light).
+
+**Traceability:** SR-DAQ-001
+
+**SWR-DAQ-002:** The software SHALL assign each supported sensor type to a predefined and unique hardware slot.
+
+**Traceability:** SR-DAQ-002
+
+**SWR-DAQ-003:** The software SHALL detect the physical presence of each sensor via a dedicated hardware detection signal prior to sensor initialization.
+
+**Traceability:** SR-DAQ-003
+
+**SWR-DAQ-004:** The software SHALL initialize and activate only sensors that are detected as present and enabled.
+
+**Traceability:** SR-DAQ-004
+
+**SWR-DAQ-005:** The software SHALL sample each enabled sensor multiple times within a single acquisition cycle (default: 10 samples per sensor per cycle).
+
+**Traceability:** SR-DAQ-005
+
+**SWR-DAQ-006:** The software SHALL apply a local filtering mechanism to raw sensor samples to produce a single filtered sensor value per acquisition cycle.
+
+**Traceability:** SR-DAQ-006
+
+**SWR-DAQ-007:** The software SHALL complete each sensor's sampling and filtering process within a bounded and deterministic time window (maximum 100ms per sensor).
+
+**Traceability:** SR-DAQ-007, CFC-TIME-02
+
+**SWR-DAQ-008:** The software SHALL generate a timestamp for each filtered sensor value upon completion of the acquisition and filtering process.
+
+**Traceability:** SR-DAQ-008
+
+**SWR-DAQ-009:** The software SHALL generate a timestamped sensor data record containing at minimum: sensor identifier, sensor type, filtered value, unit of measurement, timestamp, and data validity status.
+
+**Traceability:** SR-DAQ-009
+
+**SWR-DAQ-010:** The software SHALL maintain the most recent timestamped sensor data record in memory and make it available for persistence and on-demand communication requests.
+
+**Traceability:** SR-DAQ-010
+
+**SWR-DAQ-011:** The software SHALL NOT perform sensor acquisition during OTA_UPDATE, MC_UPDATE, or TEARDOWN states.
+
+**Traceability:** CFC-ARCH-02
+
+**SWR-DAQ-012:** The software SHALL perform sensor acquisition in a non-blocking manner.
+
+**Traceability:** CFC-TIME-01
+
+**SWR-DAQ-013:** The software SHALL use deterministic memory allocation for sensor acquisition buffers (no dynamic allocation in acquisition path).
+
+**Traceability:** CFC-TIME-02
+
+**SWR-DAQ-014:** The software SHALL publish sensor data updates via the Event System upon completion of each acquisition cycle.
+
+**Traceability:** Architecture requirement
+
+**SWR-DAQ-015:** The software SHALL exclude failed sensors from acquisition cycles as defined by the failure handling model.
+
+**Traceability:** SR-DQC-009
+
+#### 3.1.3 Data Quality & Calibration (SWR-DQC-001 through SWR-DQC-018)
+
+**SWR-DQC-001:** The software SHALL detect the physical presence of each sensor using a dedicated hardware-based detection mechanism.
+
+**Traceability:** SR-DQC-001
+
+**SWR-DQC-002:** The software SHALL perform sensor presence detection during system startup and after any reinitialization or reconfiguration event.
+
+**Traceability:** SR-DQC-002
+
+**SWR-DQC-003:** The software SHALL initialize and activate only sensors that are detected as present.
+
+**Traceability:** SR-DQC-003
+
+**SWR-DQC-004:** The software SHALL assign each physical sensor slot to a predefined sensor type.
+
+**Traceability:** SR-DQC-004
+
+**SWR-DQC-005:** The software SHALL verify that a detected sensor matches the expected sensor type for its assigned slot.
+
+**Traceability:** SR-DQC-005
+
+**SWR-DQC-006:** The software SHALL reject and report any sensor-slot mismatch as a diagnostic event.
+
+**Traceability:** SR-DQC-006
+
+**SWR-DQC-007:** The software SHALL continuously monitor sensor responsiveness and signal validity during normal operation.
+
+**Traceability:** SR-DQC-007
+
+**SWR-DQC-008:** The software SHALL detect sensor failures including disconnection, non-responsiveness, and out-of-range measurement values.
+
+**Traceability:** SR-DQC-008
+
+**SWR-DQC-009:** The software SHALL mark detected faulty sensors as defective and exclude them from data acquisition and reporting.
+
+**Traceability:** SR-DQC-009
+
+**SWR-DQC-010:** The software SHALL report detected sensor failures to the Main Hub with timestamps and failure classification.
+
+**Traceability:** SR-DQC-010
+
+**SWR-DQC-011:** The software SHALL maintain a Machine Constants dataset defining sensor configuration, calibration parameters, and communication identifiers.
+
+**Traceability:** SR-DQC-011
+
+**SWR-DQC-012:** The software SHALL store the Machine Constants dataset in non-volatile storage.
+
+**Traceability:** SR-DQC-012
+
+**SWR-DQC-013:** The software SHALL load and apply the Machine Constants dataset during system initialization.
+
+**Traceability:** SR-DQC-013
+
+**SWR-DQC-014:** The software SHALL support remote updates of the Machine Constants dataset initiated by the Main Hub.
+
+**Traceability:** SR-DQC-014
+
+**SWR-DQC-015:** The software SHALL apply updated Machine Constants only after executing a controlled teardown and reinitialization procedure.
+
+**Traceability:** SR-DQC-015
+
+**SWR-DQC-016:** The software SHALL validate Machine Constants integrity before applying updates.
+
+**Traceability:** SR-SEC-008
+
+**SWR-DQC-017:** The software SHALL NOT perform sensor calibration during OTA_UPDATE, MC_UPDATE, or TEARDOWN states.
+
+**Traceability:** CFC-ARCH-02
+
+**SWR-DQC-018:** The software SHALL access Machine Constants only through the DP component.
+
+**Traceability:** CFC-ARCH-01, CFC-DATA-01
+
+#### 3.1.4 Communication (SWR-COM-001 through SWR-COM-015)
+
+**SWR-COM-001:** The software SHALL support bidirectional communication between the Sensor Hub and the Main Hub.
+
+**Traceability:** SR-COM-001
+
+**SWR-COM-002:** The software SHALL transmit sensor data, diagnostics information, and system status to the Main Hub.
+
+**Traceability:** SR-COM-002
+
+**SWR-COM-003:** The software SHALL receive commands, configuration updates, and firmware update requests from the Main Hub.
+
+**Traceability:** SR-COM-003
+
+**SWR-COM-004:** The software SHALL monitor the status of the communication link with the Main Hub and report link availability and failure conditions.
+
+**Traceability:** SR-COM-004
+
+**SWR-COM-005:** The software SHALL support on-demand requests from the Main Hub for sensor data.
+
+**Traceability:** SR-COM-005
+
+**SWR-COM-006:** The software SHALL respond to on-demand data requests with the most recent timestamped sensor data.
+
+**Traceability:** SR-COM-006
+
+**SWR-COM-007:** The software SHALL include sensor status and data validity information in on-demand data responses.
+
+**Traceability:** SR-COM-007
+
+**SWR-COM-008:** The software SHALL support limited peer-to-peer communication between Sensor Hubs for connectivity checks and time synchronization.
+
+**Traceability:** SR-COM-008, SR-COM-009
+
+**SWR-COM-009:** The software SHALL ensure that peer Sensor Hub communication does not interfere with Main Hub communication or control operations.
+
+**Traceability:** SR-COM-010
+
+**SWR-COM-010:** The software SHALL encrypt all communication with the Main Hub using authenticated encryption.
+
+**Traceability:** SR-SEC-009, CFC-SEC-02
+
+**SWR-COM-011:** The software SHALL ensure integrity and authenticity of all transmitted and received messages.
+
+**Traceability:** SR-SEC-010
+
+**SWR-COM-012:** The software SHALL limit communication operations during TEARDOWN state to session closure only.
+
+**Traceability:** CFC-ARCH-02
+
+**SWR-COM-013:** The software SHALL perform communication operations in a non-blocking manner.
+
+**Traceability:** CFC-TIME-01
+
+**SWR-COM-014:** The software SHALL report communication link failures as diagnostic events according to the failure handling model.
+
+**Traceability:** SR-COM-004, Failure Handling Model
+
+**SWR-COM-015:** The software SHALL detect and report communication security violations to the Main Hub.
+
+**Traceability:** SR-SEC-012
+
+#### 3.1.5 Diagnostics & Health Monitoring (SWR-DIAG-001 through SWR-DIAG-018)
+
+**SWR-DIAG-001:** The software SHALL implement a diagnostic code framework for reporting system health conditions, warnings, errors, and fatal faults.
+
+**Traceability:** SR-DIAG-001
+
+**SWR-DIAG-002:** The software SHALL assign a unique diagnostic code to each detected fault or abnormal condition.
+
+**Traceability:** SR-DIAG-002
+
+**SWR-DIAG-003:** The software SHALL classify diagnostic codes by severity level (INFO, WARNING, ERROR, FATAL).
+
+**Traceability:** SR-DIAG-003
+
+**SWR-DIAG-004:** The software SHALL associate each diagnostic event with a timestamp and the originating system component.
+
+**Traceability:** SR-DIAG-004
+
+**SWR-DIAG-005:** The software SHALL persist diagnostic events in non-volatile storage.
+
+**Traceability:** SR-DIAG-005
+
+**SWR-DIAG-006:** The software SHALL retain diagnostic data across system resets and power cycles.
+
+**Traceability:** SR-DIAG-006
+
+**SWR-DIAG-007:** The software SHALL implement a bounded diagnostic storage mechanism with a defined overwrite or rollover policy.
+
+**Traceability:** SR-DIAG-007
+
+**SWR-DIAG-008:** The software SHALL provide a diagnostic session interface for accessing diagnostic and system health data.
+
+**Traceability:** SR-DIAG-008
+
+**SWR-DIAG-009:** The software SHALL allow authorized diagnostic sessions to retrieve stored diagnostic events.
+
+**Traceability:** SR-DIAG-009
+
+**SWR-DIAG-010:** The software SHALL allow authorized diagnostic sessions to clear stored diagnostic records.
+
+**Traceability:** SR-DIAG-010
+
+**SWR-DIAG-011:** The software SHALL ensure that diagnostic sessions do not interfere with normal sensor acquisition or communication operations.
+
+**Traceability:** SR-DIAG-011, CFC-DBG-01
+
+**SWR-DIAG-012:** The software SHALL trigger state transitions based on diagnostic severity according to the failure handling model.
+
+**Traceability:** Failure Handling Model, SR-SYS-002
+
+**SWR-DIAG-013:** The software SHALL implement fault latching behavior as defined in the failure handling model.
+
+**Traceability:** Failure Handling Model
+
+**SWR-DIAG-014:** The software SHALL implement fault escalation rules as defined in the failure handling model.
+
+**Traceability:** Failure Handling Model
+
+**SWR-DIAG-015:** The software SHALL report WARNING, ERROR, and FATAL diagnostic events to the Main Hub.
+
+**Traceability:** SR-COM-002
+
+**SWR-DIAG-016:** The software SHALL provide diagnostic information through the local OLED menu interface.
+
+**Traceability:** SR-SYS-010
+
+**SWR-DIAG-017:** The software SHALL access diagnostic storage only through the DP component.
+
+**Traceability:** CFC-ARCH-01, CFC-DATA-01
+
+**SWR-DIAG-018:** The software SHALL NOT generate new diagnostic events during TEARDOWN state (except teardown-specific diagnostics).
+
+**Traceability:** CFC-ARCH-02
+
+#### 3.1.6 Persistence & Data Management (SWR-DATA-001 through SWR-DATA-015)
+
+**SWR-DATA-001:** The software SHALL persist timestamped sensor data in non-volatile storage.
+
+**Traceability:** SR-DATA-001
+
+**SWR-DATA-002:** The software SHALL store sensor data together with sensor identifiers, timestamps, and validity status.
+
+**Traceability:** SR-DATA-002
+
+**SWR-DATA-003:** The software SHALL support configurable data retention and overwrite policies for persisted sensor data.
+
+**Traceability:** SR-DATA-003
+
+**SWR-DATA-004:** The software SHALL provide a Data Persistence (DP) component as the sole interface for persistent data access.
+
+**Traceability:** SR-DATA-004, CFC-ARCH-01
+
+**SWR-DATA-005:** The software SHALL prevent application and feature modules from directly accessing storage hardware.
+
+**Traceability:** SR-DATA-005, CFC-ARCH-01
+
+**SWR-DATA-006:** The DP component SHALL support serialization and deserialization of structured system data.
+
+**Traceability:** SR-DATA-006
+
+**SWR-DATA-007:** The software SHALL flush all critical runtime data to non-volatile storage before entering a controlled teardown or reset state.
+
+**Traceability:** SR-DATA-007, SR-SYS-005
+
+**SWR-DATA-008:** The software SHALL protect data integrity during firmware updates and machine constant updates.
+
+**Traceability:** SR-DATA-008
+
+**SWR-DATA-009:** The software SHALL verify successful data persistence before completing a system state transition.
+
+**Traceability:** SR-DATA-009, CFC-DATA-02
+
+**SWR-DATA-010:** The software SHALL NOT perform data write operations during TEARDOWN state unless explicitly authorized by the System Manager.
+
+**Traceability:** CFC-DATA-02
+
+**SWR-DATA-011:** The software SHALL ensure persistence completion is confirmed before state transitions.
+
+**Traceability:** CFC-DATA-02
+
+**SWR-DATA-012:** The software SHALL handle SD card failures gracefully by entering SD_DEGRADED state and disabling persistence writes.
+
+**Traceability:** System State Machine Specification
+
+**SWR-DATA-013:** The software SHALL implement wear-aware storage management to prevent premature SD card failure.
+
+**Traceability:** Quality requirement
+
+**SWR-DATA-014:** The software SHALL maintain a single source of truth for runtime and persistent data through the DP component.
+
+**Traceability:** CFC-DATA-01
+
+**SWR-DATA-015:** The software SHALL NOT allow features to maintain private persistent copies of shared system data.
+
+**Traceability:** CFC-DATA-01
+
+#### 3.1.7 Firmware Update (OTA) (SWR-OTA-001 through SWR-OTA-020)
+
+**SWR-OTA-001:** The software SHALL support OTA update negotiation initiated by the Main Hub.
+
+**Traceability:** SR-OTA-001
+
+**SWR-OTA-002:** The software SHALL verify internal readiness conditions before accepting an OTA update request.
+
+**Traceability:** SR-OTA-002
+
+**SWR-OTA-003:** The software SHALL explicitly acknowledge or reject OTA update requests.
+
+**Traceability:** SR-OTA-003
+
+**SWR-OTA-004:** The software SHALL receive firmware images over the established communication interface.
+
+**Traceability:** SR-OTA-004
+
+**SWR-OTA-005:** The software SHALL store received firmware images in non-volatile storage prior to validation.
+
+**Traceability:** SR-OTA-005
+
+**SWR-OTA-006:** The software SHALL prevent overwriting the active firmware during firmware reception.
+
+**Traceability:** SR-OTA-006
+
+**SWR-OTA-007:** The software SHALL validate the integrity of received firmware images before activation.
+
+**Traceability:** SR-OTA-007
+
+**SWR-OTA-008:** The software SHALL reject firmware images that fail integrity validation.
+
+**Traceability:** SR-OTA-008
+
+**SWR-OTA-009:** The software SHALL report firmware validation and OTA status to the Main Hub.
+
+**Traceability:** SR-OTA-009
+
+**SWR-OTA-010:** The software SHALL execute a controlled teardown procedure prior to firmware activation.
+
+**Traceability:** SR-OTA-010, SR-SYS-004
+
+**SWR-OTA-011:** The software SHALL persist critical runtime data and calibration data before flashing new firmware.
+
+**Traceability:** SR-OTA-011, SR-SYS-005
+
+**SWR-OTA-012:** The software SHALL activate new firmware only after successful integrity validation.
+
+**Traceability:** SR-OTA-012
+
+**SWR-OTA-013:** The software SHALL reboot into the new firmware after successful activation.
+
+**Traceability:** SR-OTA-013
+
+**SWR-OTA-014:** The software SHALL use encrypted and authenticated communication channels for OTA firmware updates.
+
+**Traceability:** SR-SEC-011, CFC-SEC-02
+
+**SWR-OTA-015:** The software SHALL transition to OTA_PREP state upon accepting an OTA request.
+
+**Traceability:** System State Machine Specification
+
+**SWR-OTA-016:** The software SHALL NOT allow OTA operations during WARNING, FAULT, SERVICE, or SD_DEGRADED states.
+
+**Traceability:** System State Machine Specification, CFC-ARCH-02
+
+**SWR-OTA-017:** The software SHALL complete OTA operations within a maximum duration of 10 minutes.
+
+**Traceability:** Quality requirement
+
+**SWR-OTA-018:** The software SHALL handle OTA failures by transitioning to FAULT state and reporting the failure.
+
+**Traceability:** System State Machine Specification, Failure Handling Model
+
+**SWR-OTA-019:** The software SHALL protect active firmware from corruption during OTA operations.
+
+**Traceability:** SR-OTA-006
+
+**SWR-OTA-020:** The software SHALL verify firmware authenticity using secure boot mechanisms before execution.
+
+**Traceability:** SR-SEC-001, SR-SEC-002
+
+#### 3.1.8 Security & Safety (SWR-SEC-001 through SWR-SEC-020)
+
+**SWR-SEC-001:** The software SHALL verify the authenticity of the firmware image before execution during every boot cycle.
+
+**Traceability:** SR-SEC-001, CFC-SEC-01
+
+**SWR-SEC-002:** The software SHALL prevent execution of firmware images that fail cryptographic verification.
+
+**Traceability:** SR-SEC-002
+
+**SWR-SEC-003:** The software SHALL enter BOOT_FAILURE state when secure boot verification fails.
+
+**Traceability:** SR-SEC-003, System State Machine Specification
+
+**SWR-SEC-004:** The software SHALL protect the root-of-trust against unauthorized modification.
+
+**Traceability:** SR-SEC-004
+
+**SWR-SEC-005:** The software SHALL protect sensitive data stored in internal flash memory from unauthorized access.
+
+**Traceability:** SR-SEC-005
+
+**SWR-SEC-006:** The software SHALL support encryption of sensitive data stored in external storage devices.
+
+**Traceability:** SR-SEC-006
+
+**SWR-SEC-007:** The software SHALL restrict access to cryptographic keys to authorized system components only.
+
+**Traceability:** SR-SEC-007
+
+**SWR-SEC-008:** The software SHALL ensure integrity of stored configuration, calibration, and machine constant data.
+
+**Traceability:** SR-SEC-008
+
+**SWR-SEC-009:** The software SHALL encrypt all communication with the Main Hub.
+
+**Traceability:** SR-SEC-009, CFC-SEC-02
+
+**SWR-SEC-010:** The software SHALL ensure integrity and authenticity of all transmitted and received messages.
+
+**Traceability:** SR-SEC-010
+
+**SWR-SEC-011:** The software SHALL use encrypted and authenticated communication channels for OTA firmware updates.
+
+**Traceability:** SR-SEC-011, CFC-SEC-02
+
+**SWR-SEC-012:** The software SHALL detect and report communication and security violations to the Main Hub.
+
+**Traceability:** SR-SEC-012
+
+**SWR-SEC-013:** The software SHALL enable secure boot and flash protection before any application-level logic executes.
+
+**Traceability:** CFC-SEC-01
+
+**SWR-SEC-014:** The software SHALL authenticate debug sessions before allowing debug operations.
+
+**Traceability:** SR-SYS-013, CFC-DBG-01
+
+**SWR-SEC-015:** The software SHALL NOT allow debug sessions to bypass security or safety mechanisms.
+
+**Traceability:** CFC-DBG-01
+
+**SWR-SEC-016:** The software SHALL report security violations as FATAL diagnostic events.
+
+**Traceability:** Failure Handling Model
+
+**SWR-SEC-017:** The software SHALL protect cryptographic keys during power loss and system resets.
+
+**Traceability:** Quality requirement
+
+**SWR-SEC-018:** The software SHALL implement secure session establishment for all external communication.
+
+**Traceability:** SR-SEC-009
+
+**SWR-SEC-019:** The software SHALL validate message integrity on every received message.
+
+**Traceability:** SR-SEC-010
+
+**SWR-SEC-020:** The software SHALL prevent downgrade attacks by verifying firmware version integrity.
+
+**Traceability:** Quality requirement
+
+### 3.2 Interface Requirements
+
+#### 3.2.1 External Interfaces
+
+**SWR-IF-001:** The software SHALL provide a communication interface to the Main Hub supporting bidirectional data exchange.
+
+**Traceability:** SR-COM-001
+
+**SWR-IF-002:** The software SHALL provide sensor interfaces supporting I2C, SPI, UART, and analog protocols.
+
+**Traceability:** Architecture requirement
+
+**SWR-IF-003:** The software SHALL provide an I2C interface for OLED display communication.
+
+**Traceability:** SR-SYS-007
+
+**SWR-IF-004:** The software SHALL provide GPIO interfaces for button inputs (Up, Down, Select).
+
+**Traceability:** SR-SYS-009
+
+**SWR-IF-005:** The software SHALL provide storage interfaces for SD card and NVM access.
+
+**Traceability:** Architecture requirement
+
+**SWR-IF-006:** The software SHALL provide a debug interface (UART/USB) for diagnostic and debug sessions.
+
+**Traceability:** SR-SYS-011, SR-SYS-012
+
+#### 3.2.2 Internal Interfaces
+
+**SWR-IF-007:** The software SHALL provide an Event System interface for cross-component communication.
+
+**Traceability:** Architecture requirement
+
+**SWR-IF-008:** The software SHALL provide a Data Pool interface for runtime data access.
+
+**Traceability:** Architecture requirement
+
+**SWR-IF-009:** The software SHALL provide a Data Persistence (DP) component interface for persistent storage access.
+
+**Traceability:** SR-DATA-004, CFC-ARCH-01
+
+**SWR-IF-010:** The software SHALL provide a System State Manager interface for state queries and transitions.
+
+**Traceability:** SR-SYS-001
+
+**SWR-IF-011:** The software SHALL provide a Diagnostics interface for fault reporting and querying.
+
+**Traceability:** SR-DIAG-001
+
+**SWR-IF-012:** The software SHALL provide an Error Handler interface for fault classification and escalation.
+
+**Traceability:** Failure Handling Model
+
+### 3.3 Performance Requirements
+
+**SWR-PERF-001:** The software SHALL complete sensor acquisition cycles within 100ms per sensor.
+
+**Traceability:** SR-DAQ-007, CFC-TIME-02
+
+**SWR-PERF-002:** The software SHALL complete state transitions within 50ms (except INIT → RUNNING: 5s, TEARDOWN: 500ms).
+
+**Traceability:** System State Machine Specification
+
+**SWR-PERF-003:** The software SHALL complete data persistence operations within 200ms.
+
+**Traceability:** Quality requirement
+
+**SWR-PERF-004:** The software SHALL complete OTA operations within 10 minutes.
+
+**Traceability:** SWR-OTA-017
+
+**SWR-PERF-005:** The software SHALL maintain CPU utilization below 80% during normal operation.
+
+**Traceability:** Quality requirement
+
+**SWR-PERF-006:** The software SHALL maintain RAM usage below 60% of available memory.
+
+**Traceability:** Quality requirement
+
+**SWR-PERF-007:** The software SHALL respond to Main Hub data requests within 100ms.
+
+**Traceability:** SR-COM-005, SR-COM-006
+
+**SWR-PERF-008:** The software SHALL detect communication link failures within 30 seconds.
+
+**Traceability:** SR-COM-004
+
+### 3.4 Design Constraints
+
+**SWR-DESIGN-001:** The software SHALL NOT use dynamic memory allocation in sensor acquisition paths.
+
+**Traceability:** CFC-TIME-02
+
+**SWR-DESIGN-002:** The software SHALL implement all features as non-blocking operations.
+
+**Traceability:** CFC-TIME-01
+
+**SWR-DESIGN-003:** The software SHALL access hardware only through driver and OSAL layers.
+
+**Traceability:** CFC-ARCH-01
+
+**SWR-DESIGN-004:** The software SHALL access persistent storage only through the DP component.
+
+**Traceability:** CFC-ARCH-01, CFC-DATA-01
+
+**SWR-DESIGN-005:** The software SHALL respect system state restrictions for all operations.
+
+**Traceability:** CFC-ARCH-02
+
+**SWR-DESIGN-006:** The software SHALL use the Event System for all cross-component communication.
+
+**Traceability:** Architecture requirement
+
+### 3.5 Quality Attributes
+
+**SWR-QUAL-001:** The software SHALL recover gracefully from power interruptions (< 1 second).
+
+**Traceability:** System Assumptions
+
+**SWR-QUAL-002:** The software SHALL handle SD card failures without system failure.
+
+**Traceability:** System Limitations
+
+**SWR-QUAL-003:** The software SHALL maintain data integrity during firmware updates.
+
+**Traceability:** SR-DATA-008
+
+**SWR-QUAL-004:** The software SHALL prevent unauthorized firmware execution.
+
+**Traceability:** SR-SEC-001, SR-SEC-002
+
+**SWR-QUAL-005:** The software SHALL provide deterministic behavior under all operational conditions.
+
+**Traceability:** CFC-TIME-02
+
+## 4. Annexes
+
+See separate annex documents:
+- **Annex A:** Software Requirements Traceability Matrix (`Annex_A_Traceability.md`)
+- **Annex B:** External Interface Specifications (`Annex_B_Interfaces.md`)
+- **Annex C:** Timing and Resource Budgets (`Annex_C_Budgets.md`)
--- a/draft/SRS_old/Traceability_SWRS.csv
+++ b/draft/SRS_old/Traceability_SWRS.csv
@@ -0,0 +1,168 @@
+SWR_ID,Type,Status,Title,Description,SR_ID,Feature_ID,Component,Test_ID
+SWR-SYS-001,Software Requirement,Specified,FSM Implementation,The software SHALL implement a finite state machine (FSM) with the following states: INIT, BOOT_FAILURE, RUNNING, WARNING, FAULT, OTA_PREP, OTA_UPDATE, MC_UPDATE, TEARDOWN, SERVICE, SD_DEGRADED.,SR-SYS-001,F-SYS-01,STM,T-SYS-001
+SWR-SYS-002,Software Requirement,Specified,FSM Transition Enforcement,The software SHALL enforce valid state transitions as defined in the System State Machine Specification.,SR-SYS-001,F-SYS-01,STM,T-SYS-002
+SWR-SYS-003,Software Requirement,Specified,State-Based Operation Restriction,The software SHALL restrict feature operations based on the current system state according to per-state execution rules.,SR-SYS-002,F-SYS-01,STM,T-SYS-003
+SWR-SYS-004,Software Requirement,Specified,State Transition Notification,The software SHALL notify all registered components when a state transition occurs via the Event System.,SR-SYS-003,F-SYS-01,"STM, Event System",T-SYS-004
+SWR-SYS-005,Software Requirement,Specified,Controlled Teardown Execution,The software SHALL execute a controlled teardown sequence before firmware updates, machine constant updates, or system resets.,SR-SYS-004,F-SYS-02,STM,T-SYS-005
+SWR-SYS-006,Software Requirement,Specified,Critical Data Persistence Before Teardown,The software SHALL persist all critical runtime data before completing a teardown sequence.,SR-SYS-005,F-SYS-02,"STM, Persistence",T-SYS-006
+SWR-SYS-007,Software Requirement,Specified,Data Integrity Protection During Shutdown,The software SHALL prevent data corruption during teardown and reset operations.,SR-SYS-006,F-SYS-02,"STM, Persistence",T-SYS-007
+SWR-SYS-008,Software Requirement,Specified,OLED Display Interface,The software SHALL provide a local OLED display interface using I2C communication protocol.,SR-SYS-007,F-SYS-03,HMI,T-SYS-008
+SWR-SYS-009,Software Requirement,Specified,System Information Display,The software SHALL display connectivity status, system state, connected sensor summary, and time/date on the OLED display.,SR-SYS-008,F-SYS-03,HMI,T-SYS-009
+SWR-SYS-010,Software Requirement,Specified,Button-Based Menu Navigation,The software SHALL provide menu navigation using Up, Down, and Select buttons.,SR-SYS-009,F-SYS-03,HMI,T-SYS-010
+SWR-SYS-011,Software Requirement,Specified,Local Diagnostic and Health Menus,The software SHALL provide diagnostic, sensor, and health information through the local OLED menu interface.,SR-SYS-010,F-SYS-03,"HMI, Diagnostics",T-SYS-011
+SWR-SYS-012,Software Requirement,Specified,Diagnostic Session Support,The software SHALL support diagnostic sessions for retrieving system status and diagnostic data.,SR-SYS-011,F-SYS-04,Debug Session Manager,T-SYS-012
+SWR-SYS-013,Software Requirement,Specified,Debug Session Support,The software SHALL support debug sessions allowing controlled engineering commands.,SR-SYS-012,F-SYS-04,Debug Session Manager,T-SYS-013
+SWR-SYS-014,Software Requirement,Specified,Authorized Debug Access Control,The software SHALL restrict debug session actions to authorized engineering access only.,SR-SYS-013,F-SYS-04,"Debug Session Manager, Security",T-SYS-014
+SWR-SYS-015,Software Requirement,Specified,Non-Intrusive Debug Sessions,The software SHALL ensure debug sessions do not interfere with normal sensor acquisition or communication operations.,SR-SYS-013,F-SYS-04,Debug Session Manager,T-SYS-015
+SWR-DAQ-001,Software Requirement,Specified,Multi-Sensor Environmental Data Acquisition,The software SHALL support simultaneous acquisition of environmental data from multiple sensor types (temperature, humidity, CO2, NH3, VOC, particulate matter, light).,SR-DAQ-001,F-DAQ-01,Sensor Manager,T-DAQ-001
+SWR-DAQ-002,Software Requirement,Specified,Dedicated Sensor Slot Mapping,The software SHALL assign each supported sensor type to a predefined and unique hardware slot.,SR-DAQ-002,F-DAQ-01,Sensor Manager,T-DAQ-002
+SWR-DAQ-003,Software Requirement,Specified,Sensor Presence Detection,The software SHALL detect the physical presence of each sensor via a dedicated hardware detection signal prior to sensor initialization.,SR-DAQ-003,F-DAQ-01,"Sensor Manager, Sensor Drivers",T-DAQ-003
+SWR-DAQ-004,Software Requirement,Specified,Conditional Sensor Initialization,The software SHALL initialize and activate only sensors that are detected as present and enabled.,SR-DAQ-004,F-DAQ-01,Sensor Manager,T-DAQ-004
+SWR-DAQ-005,Software Requirement,Specified,High-Frequency Sensor Sampling,The software SHALL sample each enabled sensor multiple times within a single acquisition cycle (default: 10 samples per sensor per cycle).,SR-DAQ-005,F-DAQ-02,Sensor Manager,T-DAQ-005
+SWR-DAQ-006,Software Requirement,Specified,Local Sensor Data Filtering,The software SHALL apply a local filtering mechanism to raw sensor samples to produce a single filtered sensor value per acquisition cycle.,SR-DAQ-006,F-DAQ-02,Sensor Manager,T-DAQ-006
+SWR-DAQ-007,Software Requirement,Specified,Deterministic Sampling Window,The software SHALL complete each sensor's sampling and filtering process within a bounded and deterministic time window (maximum 100ms per sensor).,SR-DAQ-007,F-DAQ-02,Sensor Manager,T-DAQ-007
+SWR-DAQ-008,Software Requirement,Specified,Timestamp Generation for Sensor Data,The software SHALL generate a timestamp for each filtered sensor value upon completion of the acquisition and filtering process.,SR-DAQ-008,F-DAQ-03,"Sensor Manager, Time Utils",T-DAQ-008
+SWR-DAQ-009,Software Requirement,Specified,Timestamped Sensor Data Record Structure,The software SHALL generate a timestamped sensor data record containing at minimum: sensor identifier, sensor type, filtered value, unit of measurement, timestamp, and data validity status.,SR-DAQ-009,F-DAQ-03,Sensor Manager,T-DAQ-009
+SWR-DAQ-010,Software Requirement,Specified,Availability of Latest Sensor Data,The software SHALL maintain the most recent timestamped sensor data record in memory and make it available for persistence and on-demand communication requests.,SR-DAQ-010,F-DAQ-03,"Sensor Manager, Data Pool",T-DAQ-010
+SWR-DAQ-011,Software Requirement,Specified,State-Restricted Sensor Acquisition,The software SHALL NOT perform sensor acquisition during OTA_UPDATE, MC_UPDATE, or TEARDOWN states.,CFC-ARCH-02,F-DAQ-01,Sensor Manager,T-DAQ-011
+SWR-DAQ-012,Software Requirement,Specified,Non-Blocking Sensor Acquisition,The software SHALL perform sensor acquisition in a non-blocking manner.,CFC-TIME-01,F-DAQ-02,Sensor Manager,T-DAQ-012
+SWR-DAQ-013,Software Requirement,Specified,Deterministic Memory Allocation,The software SHALL use deterministic memory allocation for sensor acquisition buffers (no dynamic allocation in acquisition path).,CFC-TIME-02,F-DAQ-02,Sensor Manager,T-DAQ-013
+SWR-DAQ-014,Software Requirement,Specified,Sensor Data Event Publishing,The software SHALL publish sensor data updates via the Event System upon completion of each acquisition cycle.,Architecture Requirement,F-DAQ-03,"Sensor Manager, Event System",T-DAQ-014
+SWR-DAQ-015,Software Requirement,Specified,Failed Sensor Exclusion,The software SHALL exclude failed sensors from acquisition cycles as defined by the failure handling model.,SR-DQC-009,F-DAQ-01,Sensor Manager,T-DAQ-015
+SWR-DQC-001,Software Requirement,Specified,Detect Sensor Presence,The software SHALL detect the physical presence of each sensor using a dedicated hardware-based detection mechanism.,SR-DQC-001,F-DQC-01,"Sensor Manager, Sensor Drivers",T-DQC-001
+SWR-DQC-002,Software Requirement,Specified,Perform Sensor Detection During Initialization,The software SHALL perform sensor presence detection during system startup and after any reinitialization or reconfiguration event.,SR-DQC-002,F-DQC-01,Sensor Manager,T-DQC-002
+SWR-DQC-003,Software Requirement,Specified,Conditional Sensor Initialization,The software SHALL initialize and activate only sensors that are detected as present.,SR-DQC-003,F-DQC-01,Sensor Manager,T-DQC-003
+SWR-DQC-004,Software Requirement,Specified,Assign Fixed Sensor Slot Types,The software SHALL assign each physical sensor slot to a predefined sensor type.,SR-DQC-004,F-DQC-02,Sensor Manager,T-DQC-004
+SWR-DQC-005,Software Requirement,Specified,Verify Sensor Type Compatibility,The software SHALL verify that a detected sensor matches the expected sensor type for its assigned slot.,SR-DQC-005,F-DQC-02,Sensor Manager,T-DQC-005
+SWR-DQC-006,Software Requirement,Specified,Reject Invalid Sensor Configurations,The software SHALL reject and report any sensor-slot mismatch as a diagnostic event.,SR-DQC-006,F-DQC-02,"Sensor Manager, Diagnostics",T-DQC-006
+SWR-DQC-007,Software Requirement,Specified,Monitor Sensor Health,The software SHALL continuously monitor sensor responsiveness and signal validity during normal operation.,SR-DQC-007,F-DQC-03,Sensor Manager,T-DQC-007
+SWR-DQC-008,Software Requirement,Specified,Detect Sensor Failure Conditions,The software SHALL detect sensor failures including disconnection, non-responsiveness, and out-of-range measurement values.,SR-DQC-008,F-DQC-03,Sensor Manager,T-DQC-008
+SWR-DQC-009,Software Requirement,Specified,Isolate Failed Sensors,The software SHALL mark detected faulty sensors as defective and exclude them from data acquisition and reporting.,SR-DQC-009,F-DQC-03,Sensor Manager,T-DQC-009
+SWR-DQC-010,Software Requirement,Specified,Report Sensor Failures,The software SHALL report detected sensor failures to the Main Hub with timestamps and failure classification.,SR-DQC-010,F-DQC-03,"Sensor Manager, Communication",T-DQC-010
+SWR-DQC-011,Software Requirement,Specified,Maintain Machine Constants Dataset,The software SHALL maintain a Machine Constants dataset defining sensor configuration, calibration parameters, and communication identifiers.,SR-DQC-011,F-DQC-04,Machine Constant Manager,T-DQC-011
+SWR-DQC-012,Software Requirement,Specified,Persist Machine Constants,The software SHALL store the Machine Constants dataset in non-volatile storage.,SR-DQC-012,F-DQC-04,"Machine Constant Manager, Persistence",T-DQC-012
+SWR-DQC-013,Software Requirement,Specified,Load Machine Constants at Startup,The software SHALL load and apply the Machine Constants dataset during system initialization.,SR-DQC-013,F-DQC-04,Machine Constant Manager,T-DQC-013
+SWR-DQC-014,Software Requirement,Specified,Support Remote Machine Constants Update,The software SHALL support remote updates of the Machine Constants dataset initiated by the Main Hub.,SR-DQC-014,F-DQC-04,"Machine Constant Manager, Communication",T-DQC-014
+SWR-DQC-015,Software Requirement,Specified,Controlled Reinitialization After Update,The software SHALL apply updated Machine Constants only after executing a controlled teardown and reinitialization procedure.,SR-DQC-015,F-DQC-04,"Machine Constant Manager, STM",T-DQC-015
+SWR-DQC-016,Software Requirement,Specified,Machine Constants Integrity Validation,The software SHALL validate Machine Constants integrity before applying updates.,SR-SEC-008,F-DQC-04,"Machine Constant Manager, Security",T-DQC-016
+SWR-DQC-017,Software Requirement,Specified,State-Restricted Calibration,The software SHALL NOT perform sensor calibration during OTA_UPDATE, MC_UPDATE, or TEARDOWN states.,CFC-ARCH-02,F-DQC-04,Sensor Manager,T-DQC-017
+SWR-DQC-018,Software Requirement,Specified,Machine Constants Access via DP,The software SHALL access Machine Constants only through the DP component.,CFC-ARCH-01,F-DQC-04,"Machine Constant Manager, Persistence",T-DQC-018
+SWR-COM-001,Software Requirement,Specified,Bidirectional Main Hub Communication,The software SHALL support bidirectional communication between the Sensor Hub and the Main Hub.,SR-COM-001,F-COM-01,"Main Hub APIs, Network Stack",T-COM-001
+SWR-COM-002,Software Requirement,Specified,Transmit Data to Main Hub,The software SHALL transmit sensor data, diagnostics information, and system status to the Main Hub.,SR-COM-002,F-COM-01,Main Hub APIs,T-COM-002
+SWR-COM-003,Software Requirement,Specified,Receive Commands from Main Hub,The software SHALL receive commands, configuration updates, and firmware update requests from the Main Hub.,SR-COM-003,F-COM-01,Main Hub APIs,T-COM-003
+SWR-COM-004,Software Requirement,Specified,Monitor Communication Link Status,The software SHALL monitor the status of the communication link with the Main Hub and report link availability and failure conditions.,SR-COM-004,F-COM-01,Network Stack,T-COM-004
+SWR-COM-005,Software Requirement,Specified,Support On-Demand Data Requests,The software SHALL support on-demand requests from the Main Hub for sensor data.,SR-COM-005,F-COM-02,Main Hub APIs,T-COM-005
+SWR-COM-006,Software Requirement,Specified,Respond with Latest Sensor Data,The software SHALL respond to on-demand data requests with the most recent timestamped sensor data.,SR-COM-006,F-COM-02,"Main Hub APIs, Data Pool",T-COM-006
+SWR-COM-007,Software Requirement,Specified,Include Data Validity in Responses,The software SHALL include sensor status and data validity information in on-demand data responses.,SR-COM-007,F-COM-02,Main Hub APIs,T-COM-007
+SWR-COM-008,Software Requirement,Specified,Support Peer Sensor Hub Communication,The software SHALL support limited peer-to-peer communication between Sensor Hubs for connectivity checks and time synchronization.,SR-COM-008,F-COM-03,Network Stack,T-COM-008
+SWR-COM-009,Software Requirement,Specified,Isolate Peer Communication,The software SHALL ensure that peer Sensor Hub communication does not interfere with Main Hub communication or control operations.,SR-COM-010,F-COM-03,Network Stack,T-COM-009
+SWR-COM-010,Software Requirement,Specified,Encrypted Main Hub Communication,The software SHALL encrypt all communication with the Main Hub using authenticated encryption.,SR-SEC-009,F-COM-01,"Network Stack, Security",T-COM-010
+SWR-COM-011,Software Requirement,Specified,Message Integrity and Authenticity,The software SHALL ensure integrity and authenticity of all transmitted and received messages.,SR-SEC-010,F-COM-01,"Network Stack, Security",T-COM-011
+SWR-COM-012,Software Requirement,Specified,State-Restricted Communication,The software SHALL limit communication operations during TEARDOWN state to session closure only.,CFC-ARCH-02,F-COM-01,Network Stack,T-COM-012
+SWR-COM-013,Software Requirement,Specified,Non-Blocking Communication,The software SHALL perform communication operations in a non-blocking manner.,CFC-TIME-01,F-COM-01,Network Stack,T-COM-013
+SWR-COM-014,Software Requirement,Specified,Communication Link Failure Reporting,The software SHALL report communication link failures as diagnostic events according to the failure handling model.,SR-COM-004,F-COM-01,"Network Stack, Diagnostics",T-COM-014
+SWR-COM-015,Software Requirement,Specified,Security Violation Reporting,The software SHALL detect and report communication security violations to the Main Hub.,SR-SEC-012,F-COM-01,"Network Stack, Security",T-COM-015
+SWR-DIAG-001,Software Requirement,Specified,Diagnostic Code Framework,The software SHALL implement a diagnostic code framework for reporting system health conditions, warnings, errors, and fatal faults.,SR-DIAG-001,F-DIAG-01,Diagnostics Task,T-DIAG-001
+SWR-DIAG-002,Software Requirement,Specified,Assign Unique Diagnostic Codes,The software SHALL assign a unique diagnostic code to each detected fault or abnormal condition.,SR-DIAG-002,F-DIAG-01,Diagnostics Task,T-DIAG-002
+SWR-DIAG-003,Software Requirement,Specified,Classify Diagnostic Severity,The software SHALL classify diagnostic codes by severity level (INFO, WARNING, ERROR, FATAL).,SR-DIAG-003,F-DIAG-01,Diagnostics Task,T-DIAG-003
+SWR-DIAG-004,Software Requirement,Specified,Timestamp and Source Diagnostics,The software SHALL associate each diagnostic event with a timestamp and the originating system component.,SR-DIAG-004,F-DIAG-01,Diagnostics Task,T-DIAG-004
+SWR-DIAG-005,Software Requirement,Specified,Persist Diagnostic Events,The software SHALL persist diagnostic events in non-volatile storage.,SR-DIAG-005,F-DIAG-02,"Diagnostics Task, Persistence",T-DIAG-005
+SWR-DIAG-006,Software Requirement,Specified,Retain Diagnostics Across Resets,The software SHALL retain diagnostic data across system resets and power cycles.,SR-DIAG-006,F-DIAG-02,"Diagnostics Task, Persistence",T-DIAG-006
+SWR-DIAG-007,Software Requirement,Specified,Bounded Diagnostic Storage,The software SHALL implement a bounded diagnostic storage mechanism with a defined overwrite or rollover policy.,SR-DIAG-007,F-DIAG-02,"Diagnostics Task, Persistence",T-DIAG-007
+SWR-DIAG-008,Software Requirement,Specified,Provide Diagnostic Session Interface,The software SHALL provide a diagnostic session interface for accessing diagnostic and system health data.,SR-DIAG-008,F-DIAG-03,Diagnostics Task,T-DIAG-008
+SWR-DIAG-009,Software Requirement,Specified,Retrieve Diagnostic Records,The software SHALL allow authorized diagnostic sessions to retrieve stored diagnostic events.,SR-DIAG-009,F-DIAG-03,Diagnostics Task,T-DIAG-009
+SWR-DIAG-010,Software Requirement,Specified,Clear Diagnostic Records,The software SHALL allow authorized diagnostic sessions to clear stored diagnostic records.,SR-DIAG-010,F-DIAG-03,Diagnostics Task,T-DIAG-010
+SWR-DIAG-011,Software Requirement,Specified,Non-Intrusive Diagnostic Sessions,The software SHALL ensure that diagnostic sessions do not interfere with normal sensor acquisition or communication operations.,SR-DIAG-011,F-DIAG-03,Diagnostics Task,T-DIAG-011
+SWR-DIAG-012,Software Requirement,Specified,Fault-to-State Transition,The software SHALL trigger state transitions based on diagnostic severity according to the failure handling model.,Failure Handling Model,F-DIAG-01,"Diagnostics Task, Error Handler",T-DIAG-012
+SWR-DIAG-013,Software Requirement,Specified,Fault Latching Behavior,The software SHALL implement fault latching behavior as defined in the failure handling model.,Failure Handling Model,F-DIAG-01,Error Handler,T-DIAG-013
+SWR-DIAG-014,Software Requirement,Specified,Fault Escalation Rules,The software SHALL implement fault escalation rules as defined in the failure handling model.,Failure Handling Model,F-DIAG-01,Error Handler,T-DIAG-014
+SWR-DIAG-015,Software Requirement,Specified,Diagnostic Event Reporting to Main Hub,The software SHALL report WARNING, ERROR, and FATAL diagnostic events to the Main Hub.,SR-COM-002,F-DIAG-02,"Diagnostics Task, Communication",T-DIAG-015
+SWR-DIAG-016,Software Requirement,Specified,Diagnostic Information via HMI,The software SHALL provide diagnostic information through the local OLED menu interface.,SR-SYS-010,F-DIAG-03,"Diagnostics Task, HMI",T-DIAG-016
+SWR-DIAG-017,Software Requirement,Specified,Diagnostic Storage Access via DP,The software SHALL access diagnostic storage only through the DP component.,CFC-ARCH-01,F-DIAG-02,"Diagnostics Task, Persistence",T-DIAG-017
+SWR-DIAG-018,Software Requirement,Specified,State-Restricted Diagnostic Generation,The software SHALL NOT generate new diagnostic events during TEARDOWN state (except teardown-specific diagnostics).,CFC-ARCH-02,F-DIAG-01,Diagnostics Task,T-DIAG-018
+SWR-DATA-001,Software Requirement,Specified,Persistent Timestamped Sensor Data,The software SHALL persist timestamped sensor data in non-volatile storage.,SR-DATA-001,F-DATA-01,Persistence,T-DATA-001
+SWR-DATA-002,Software Requirement,Specified,Sensor Data Metadata Storage,The software SHALL store sensor data together with sensor identifiers, timestamps, and validity status.,SR-DATA-002,F-DATA-01,Persistence,T-DATA-002
+SWR-DATA-003,Software Requirement,Specified,Configurable Data Retention Policy,The software SHALL support configurable data retention and overwrite policies for persisted sensor data.,SR-DATA-003,F-DATA-01,Persistence,T-DATA-003
+SWR-DATA-004,Software Requirement,Specified,Data Persistence Component Interface,The software SHALL provide a Data Persistence (DP) component as the sole interface for persistent data access.,SR-DATA-004,F-DATA-02,Persistence,T-DATA-004
+SWR-DATA-005,Software Requirement,Specified,Storage Access Isolation,The software SHALL prevent application and feature modules from directly accessing storage hardware.,SR-DATA-005,F-DATA-02,Persistence,T-DATA-005
+SWR-DATA-006,Software Requirement,Specified,Structured Data Serialization,The DP component SHALL support serialization and deserialization of structured system data.,SR-DATA-006,F-DATA-02,Persistence,T-DATA-006
+SWR-DATA-007,Software Requirement,Specified,Data Flush Before Teardown,The software SHALL flush all critical runtime data to non-volatile storage before entering a controlled teardown or reset state.,SR-DATA-007,F-DATA-03,"Persistence, STM",T-DATA-007
+SWR-DATA-008,Software Requirement,Specified,Data Integrity During Updates,The software SHALL protect data integrity during firmware updates and machine constant updates.,SR-DATA-008,F-DATA-03,"Persistence, OTA Manager",T-DATA-008
+SWR-DATA-009,Software Requirement,Specified,Persistence Verification,The software SHALL verify successful data persistence before completing a system state transition.,SR-DATA-009,F-DATA-03,"Persistence, STM",T-DATA-009
+SWR-DATA-010,Software Requirement,Specified,State-Restricted Data Writes,The software SHALL NOT perform data write operations during TEARDOWN state unless explicitly authorized by the System Manager.,CFC-DATA-02,F-DATA-03,Persistence,T-DATA-010
+SWR-DATA-011,Software Requirement,Specified,Persistence Completion Confirmation,The software SHALL ensure persistence completion is confirmed before state transitions.,CFC-DATA-02,F-DATA-03,"Persistence, STM",T-DATA-011
+SWR-DATA-012,Software Requirement,Specified,SD Card Failure Handling,The software SHALL handle SD card failures gracefully by entering SD_DEGRADED state and disabling persistence writes.,System State Machine Specification,F-DATA-01,"Persistence, STM",T-DATA-012
+SWR-DATA-013,Software Requirement,Specified,Wear-Aware Storage Management,The software SHALL implement wear-aware storage management to prevent premature SD card failure.,Quality Requirement,F-DATA-01,Persistence,T-DATA-013
+SWR-DATA-014,Software Requirement,Specified,Single Source of Truth,The software SHALL maintain a single source of truth for runtime and persistent data through the DP component.,CFC-DATA-01,F-DATA-02,"Data Pool, Persistence",T-DATA-014
+SWR-DATA-015,Software Requirement,Specified,No Private Persistent Copies,The software SHALL NOT allow features to maintain private persistent copies of shared system data.,CFC-DATA-01,F-DATA-02,All Components,T-DATA-015
+SWR-OTA-001,Software Requirement,Specified,OTA Negotiation Support,The software SHALL support OTA update negotiation initiated by the Main Hub.,SR-OTA-001,F-OTA-01,OTA Manager,T-OTA-001
+SWR-OTA-002,Software Requirement,Specified,OTA Readiness Validation,The software SHALL verify internal readiness conditions before accepting an OTA update request.,SR-OTA-002,F-OTA-01,OTA Manager,T-OTA-002
+SWR-OTA-003,Software Requirement,Specified,OTA Acknowledgement,The software SHALL explicitly acknowledge or reject OTA update requests.,SR-OTA-003,F-OTA-01,OTA Manager,T-OTA-003
+SWR-OTA-004,Software Requirement,Specified,Firmware Reception,The software SHALL receive firmware images over the established communication interface.,SR-OTA-004,F-OTA-02,"OTA Manager, Network Stack",T-OTA-004
+SWR-OTA-005,Software Requirement,Specified,Firmware Temporary Storage,The software SHALL store received firmware images in non-volatile storage prior to validation.,SR-OTA-005,F-OTA-02,"OTA Manager, Persistence",T-OTA-005
+SWR-OTA-006,Software Requirement,Specified,Active Firmware Protection,The software SHALL prevent overwriting the active firmware during firmware reception.,SR-OTA-006,F-OTA-02,OTA Manager,T-OTA-006
+SWR-OTA-007,Software Requirement,Specified,Firmware Integrity Verification,The software SHALL validate the integrity of received firmware images before activation.,SR-OTA-007,F-OTA-03,"OTA Manager, Security",T-OTA-007
+SWR-OTA-008,Software Requirement,Specified,Firmware Rejection Handling,The software SHALL reject firmware images that fail integrity validation.,SR-OTA-008,F-OTA-03,OTA Manager,T-OTA-008
+SWR-OTA-009,Software Requirement,Specified,OTA Status Reporting,The software SHALL report firmware validation and OTA status to the Main Hub.,SR-OTA-009,F-OTA-03,"OTA Manager, Communication",T-OTA-009
+SWR-OTA-010,Software Requirement,Specified,OTA Teardown Execution,The software SHALL execute a controlled teardown procedure prior to firmware activation.,SR-OTA-010,F-OTA-04,"OTA Manager, STM",T-OTA-010
+SWR-OTA-011,Software Requirement,Specified,Data Persistence Before Flashing,The software SHALL persist critical runtime data and calibration data before flashing new firmware.,SR-OTA-011,F-OTA-04,"OTA Manager, Persistence",T-OTA-011
+SWR-OTA-012,Software Requirement,Specified,Controlled Firmware Activation,The software SHALL activate new firmware only after successful integrity validation.,SR-OTA-012,F-OTA-04,OTA Manager,T-OTA-012
+SWR-OTA-013,Software Requirement,Specified,OTA Reboot Execution,The software SHALL reboot into the new firmware after successful activation.,SR-OTA-013,F-OTA-04,OTA Manager,T-OTA-013
+SWR-OTA-014,Software Requirement,Specified,Encrypted OTA Communication,The software SHALL use encrypted and authenticated communication channels for OTA firmware updates.,SR-SEC-011,F-OTA-02,"OTA Manager, Security",T-OTA-014
+SWR-OTA-015,Software Requirement,Specified,OTA State Transition,The software SHALL transition to OTA_PREP state upon accepting an OTA request.,System State Machine Specification,F-OTA-01,"OTA Manager, STM",T-OTA-015
+SWR-OTA-016,Software Requirement,Specified,State-Restricted OTA Operations,The software SHALL NOT allow OTA operations during WARNING, FAULT, SERVICE, or SD_DEGRADED states.,System State Machine Specification,F-OTA-01,"OTA Manager, STM",T-OTA-016
+SWR-OTA-017,Software Requirement,Specified,OTA Duration Limit,The software SHALL complete OTA operations within a maximum duration of 10 minutes.,Quality Requirement,F-OTA-04,OTA Manager,T-OTA-017
+SWR-OTA-018,Software Requirement,Specified,OTA Failure Handling,The software SHALL handle OTA failures by transitioning to FAULT state and reporting the failure.,System State Machine Specification,F-OTA-04,"OTA Manager, STM",T-OTA-018
+SWR-OTA-019,Software Requirement,Specified,Active Firmware Corruption Protection,The software SHALL protect active firmware from corruption during OTA operations.,SR-OTA-006,F-OTA-02,OTA Manager,T-OTA-019
+SWR-OTA-020,Software Requirement,Specified,Firmware Authenticity Verification,The software SHALL verify firmware authenticity using secure boot mechanisms before execution.,SR-SEC-001,F-OTA-04,"OTA Manager, Security",T-OTA-020
+SWR-SEC-001,Software Requirement,Specified,Firmware Authenticity Verification,The software SHALL verify the authenticity of the firmware image before execution during every boot cycle.,SR-SEC-001,F-SEC-01,Security,T-SEC-001
+SWR-SEC-002,Software Requirement,Specified,Unauthorized Firmware Blocking,The software SHALL prevent execution of firmware images that fail cryptographic verification.,SR-SEC-002,F-SEC-01,Security,T-SEC-002
+SWR-SEC-003,Software Requirement,Specified,Secure Boot Failure Handling,The software SHALL enter BOOT_FAILURE state when secure boot verification fails.,SR-SEC-003,F-SEC-01,"Security, STM",T-SEC-003
+SWR-SEC-004,Software Requirement,Specified,Root-of-Trust Protection,The software SHALL protect the root-of-trust against unauthorized modification.,SR-SEC-004,F-SEC-01,Security,T-SEC-004
+SWR-SEC-005,Software Requirement,Specified,Flash Data Access Protection,The software SHALL protect sensitive data stored in internal flash memory from unauthorized access.,SR-SEC-005,F-SEC-02,Security,T-SEC-005
+SWR-SEC-006,Software Requirement,Specified,Encrypted External Storage,The software SHALL support encryption of sensitive data stored in external storage devices.,SR-SEC-006,F-SEC-02,"Security, Persistence",T-SEC-006
+SWR-SEC-007,Software Requirement,Specified,Cryptographic Key Isolation,The software SHALL restrict access to cryptographic keys to authorized system components only.,SR-SEC-007,F-SEC-02,Security,T-SEC-007
+SWR-SEC-008,Software Requirement,Specified,Stored Data Integrity Assurance,The software SHALL ensure integrity of stored configuration, calibration, and machine constant data.,SR-SEC-008,F-SEC-02,"Security, Persistence",T-SEC-008
+SWR-SEC-009,Software Requirement,Specified,Encrypted Main Hub Communication,The software SHALL encrypt all communication with the Main Hub.,SR-SEC-009,F-SEC-03,"Network Stack, Security",T-SEC-009
+SWR-SEC-010,Software Requirement,Specified,Message Integrity and Authenticity,The software SHALL ensure integrity and authenticity of all transmitted and received messages.,SR-SEC-010,F-SEC-03,"Network Stack, Security",T-SEC-010
+SWR-SEC-011,Software Requirement,Specified,Secure OTA Data Transfer,The software SHALL use encrypted and authenticated communication channels for OTA firmware updates.,SR-SEC-011,F-SEC-03,"OTA Manager, Security",T-SEC-011
+SWR-SEC-012,Software Requirement,Specified,Security Violation Reporting,The software SHALL detect and report communication and security violations to the Main Hub.,SR-SEC-012,F-SEC-03,"Security, Communication",T-SEC-012
+SWR-SEC-013,Software Requirement,Specified,Security First Initialization,The software SHALL enable secure boot and flash protection before any application-level logic executes.,CFC-SEC-01,F-SEC-01,Security,T-SEC-013
+SWR-SEC-014,Software Requirement,Specified,Debug Session Authentication,The software SHALL authenticate debug sessions before allowing debug operations.,SR-SYS-013,F-SEC-03,"Security, Debug Session Manager",T-SEC-014
+SWR-SEC-015,Software Requirement,Specified,Debug Security Bypass Prevention,The software SHALL NOT allow debug sessions to bypass security or safety mechanisms.,CFC-DBG-01,F-SEC-03,"Security, Debug Session Manager",T-SEC-015
+SWR-SEC-016,Software Requirement,Specified,Security Violation Diagnostic Reporting,The software SHALL report security violations as FATAL diagnostic events.,Failure Handling Model,F-SEC-01,"Security, Diagnostics",T-SEC-016
+SWR-SEC-017,Software Requirement,Specified,Cryptographic Key Protection,The software SHALL protect cryptographic keys during power loss and system resets.,Quality Requirement,F-SEC-02,Security,T-SEC-017
+SWR-SEC-018,Software Requirement,Specified,Secure Session Establishment,The software SHALL implement secure session establishment for all external communication.,SR-SEC-009,F-SEC-03,"Network Stack, Security",T-SEC-018
+SWR-SEC-019,Software Requirement,Specified,Message Integrity Validation,The software SHALL validate message integrity on every received message.,SR-SEC-010,F-SEC-03,"Network Stack, Security",T-SEC-019
+SWR-SEC-020,Software Requirement,Specified,Downgrade Attack Prevention,The software SHALL prevent downgrade attacks by verifying firmware version integrity.,Quality Requirement,F-SEC-01,"Security, OTA Manager",T-SEC-020
+SWR-IF-001,Software Requirement,Specified,Main Hub Communication Interface,The software SHALL provide a communication interface to the Main Hub supporting bidirectional data exchange.,SR-COM-001,F-COM-01,"Main Hub APIs, Network Stack",T-IF-001
+SWR-IF-002,Software Requirement,Specified,Sensor Interfaces,The software SHALL provide sensor interfaces supporting I2C, SPI, UART, and analog protocols.,Architecture Requirement,F-DAQ-01,Sensor Drivers,T-IF-002
+SWR-IF-003,Software Requirement,Specified,OLED Display Interface,The software SHALL provide an I2C interface for OLED display communication.,SR-SYS-007,F-SYS-03,HMI,T-IF-003
+SWR-IF-004,Software Requirement,Specified,Button Input Interfaces,The software SHALL provide GPIO interfaces for button inputs (Up, Down, Select).,SR-SYS-009,F-SYS-03,HMI,T-IF-004
+SWR-IF-005,Software Requirement,Specified,Storage Interfaces,The software SHALL provide storage interfaces for SD card and NVM access.,Architecture Requirement,F-DATA-01,"SD Card Driver, NVM Driver",T-IF-005
+SWR-IF-006,Software Requirement,Specified,Debug Interface,The software SHALL provide a debug interface (UART/USB) for diagnostic and debug sessions.,SR-SYS-011,F-SYS-04,"Debug Session Manager, UART Driver",T-IF-006
+SWR-IF-007,Software Requirement,Specified,Event System Interface,The software SHALL provide an Event System interface for cross-component communication.,Architecture Requirement,All Features,Event System,T-IF-007
+SWR-IF-008,Software Requirement,Specified,Data Pool Interface,The software SHALL provide a Data Pool interface for runtime data access.,Architecture Requirement,All Features,Data Pool,T-IF-008
+SWR-IF-009,Software Requirement,Specified,Data Persistence Interface,The software SHALL provide a Data Persistence (DP) component interface for persistent storage access.,SR-DATA-004,F-DATA-02,Persistence,T-IF-009
+SWR-IF-010,Software Requirement,Specified,System State Manager Interface,The software SHALL provide a System State Manager interface for state queries and transitions.,SR-SYS-001,F-SYS-01,STM,T-IF-010
+SWR-IF-011,Software Requirement,Specified,Diagnostics Interface,The software SHALL provide a Diagnostics interface for fault reporting and querying.,SR-DIAG-001,F-DIAG-01,Diagnostics Task,T-IF-011
+SWR-IF-012,Software Requirement,Specified,Error Handler Interface,The software SHALL provide an Error Handler interface for fault classification and escalation.,Failure Handling Model,All Features,Error Handler,T-IF-012
+SWR-PERF-001,Software Requirement,Specified,Sensor Acquisition Cycle Timing,The software SHALL complete sensor acquisition cycles within 100ms per sensor.,SR-DAQ-007,Sensor Acquisition,Sensor Manager,T-PERF-001
+SWR-PERF-002,Software Requirement,Specified,State Transition Timing,The software SHALL complete state transitions within 50ms (except INIT → RUNNING: 5s, TEARDOWN: 500ms).,System State Machine Specification,State Management,STM,T-PERF-002
+SWR-PERF-003,Software Requirement,Specified,Data Persistence Timing,The software SHALL complete data persistence operations within 200ms.,Quality Requirement,Data Persistence,Persistence,T-PERF-003
+SWR-PERF-004,Software Requirement,Specified,OTA Operation Duration,The software SHALL complete OTA operations within 10 minutes.,SWR-OTA-017,Firmware Update,OTA Manager,T-PERF-004
+SWR-PERF-005,Software Requirement,Specified,CPU Utilization Limit,The software SHALL maintain CPU utilization below 80% during normal operation.,Quality Requirement,System Performance,All Components,T-PERF-005
+SWR-PERF-006,Software Requirement,Specified,RAM Usage Limit,The software SHALL maintain RAM usage below 60% of available memory.,Quality Requirement,System Performance,All Components,T-PERF-006
+SWR-PERF-007,Software Requirement,Specified,Main Hub Response Time,The software SHALL respond to Main Hub data requests within 100ms.,SR-COM-005,Communication,"Main Hub APIs, Data Pool",T-PERF-007
+SWR-PERF-008,Software Requirement,Specified,Communication Link Failure Detection,The software SHALL detect communication link failures within 30 seconds.,SR-COM-004,Communication,Network Stack,T-PERF-008
+SWR-DESIGN-001,Software Requirement,Specified,No Dynamic Memory in Acquisition Path,The software SHALL NOT use dynamic memory allocation in sensor acquisition paths.,CFC-TIME-02,Sensor Acquisition,Sensor Manager,T-DESIGN-001
+SWR-DESIGN-002,Software Requirement,Specified,Non-Blocking Operations,The software SHALL implement all features as non-blocking operations.,CFC-TIME-01,All Features,All Components,T-DESIGN-002
+SWR-DESIGN-003,Software Requirement,Specified,Hardware Access via Drivers,The software SHALL access hardware only through driver and OSAL layers.,CFC-ARCH-01,All Features,All Components,T-DESIGN-003
+SWR-DESIGN-004,Software Requirement,Specified,Storage Access via DP,The software SHALL access persistent storage only through the DP component.,CFC-ARCH-01,All Features,All Components,T-DESIGN-004
+SWR-DESIGN-005,Software Requirement,Specified,State-Aware Operations,The software SHALL respect system state restrictions for all operations.,CFC-ARCH-02,All Features,All Components,T-DESIGN-005
+SWR-DESIGN-006,Software Requirement,Specified,Event System Communication,The software SHALL use the Event System for all cross-component communication.,Architecture Requirement,All Features,All Components,T-DESIGN-006
+SWR-QUAL-001,Software Requirement,Specified,Power Interruption Recovery,The software SHALL recover gracefully from power interruptions (< 1 second).,System Assumptions,System Reliability,All Components,T-QUAL-001
+SWR-QUAL-002,Software Requirement,Specified,SD Card Failure Handling,The software SHALL handle SD card failures without system failure.,System Limitations,Data Persistence,"Persistence, STM",T-QUAL-002
+SWR-QUAL-003,Software Requirement,Specified,Data Integrity During Updates,The software SHALL maintain data integrity during firmware updates.,SR-DATA-008,Data Integrity,"OTA Manager, Persistence",T-QUAL-003
+SWR-QUAL-004,Software Requirement,Specified,Unauthorized Firmware Prevention,The software SHALL prevent unauthorized firmware execution.,SR-SEC-001,Security,"Security, OTA Manager",T-QUAL-004
+SWR-QUAL-005,Software Requirement,Specified,Deterministic Behavior,The software SHALL provide deterministic behavior under all operational conditions.,CFC-TIME-02,System Reliability,All Components,T-QUAL-005
--- a/draft/SRS_old/VV_Matrix.md
+++ b/draft/SRS_old/VV_Matrix.md
@@ -0,0 +1,231 @@
+# Verification & Validation Matrix
+
+**Document:** SRS V&V Matrix  
+**Version:** 1.0  
+**Date:** 2025-01-19
+
+## Purpose
+
+This document maps Software Requirements (SWR-*) to verification methods (unit tests, integration tests, HIL tests) and defines acceptance criteria for each requirement.
+
+## Verification Methods
+
+| Method | Description | Scope |
+|--------|-------------|-------|
+| **UT** | Unit Test | Single component, isolated |
+| **IT** | Integration Test | Multiple components, interactions |
+| **HIL** | Hardware-In-the-Loop Test | Full system, real hardware |
+| **REV** | Review | Design/code review, static analysis |
+| **ANAL** | Analysis | Timing analysis, resource analysis |
+
+## Acceptance Criteria Format
+
+- **Pass:** Requirement satisfied
+- **Fail:** Requirement not satisfied
+- **N/A:** Not applicable for this verification method
+
+## V&V Matrix
+
+### System Management Requirements
+
+| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
+|--------|-------------|----|----|-----|-----|------|---------------------|
+| SWR-SYS-001 | FSM Implementation | ✓ | ✓ | ✓ | ✓ | - | All 11 states implemented, transitions validated |
+| SWR-SYS-002 | State Transition Enforcement | ✓ | ✓ | ✓ | ✓ | - | Invalid transitions rejected, valid transitions succeed |
+| SWR-SYS-003 | State-Based Operation Restriction | ✓ | ✓ | ✓ | ✓ | - | Operations blocked in invalid states |
+| SWR-SYS-004 | State Transition Notification | ✓ | ✓ | ✓ | - | - | All listeners notified within 50ms |
+| SWR-SYS-005 | Controlled Teardown Execution | ✓ | ✓ | ✓ | ✓ | - | Teardown completes within 500ms |
+| SWR-SYS-006 | Critical Data Persistence Before Teardown | ✓ | ✓ | ✓ | ✓ | - | All critical data flushed before teardown complete |
+| SWR-SYS-007 | Data Integrity Protection During Shutdown | ✓ | ✓ | ✓ | ✓ | - | No data corruption during teardown/reset |
+| SWR-SYS-008 | OLED Display Interface | ✓ | ✓ | ✓ | ✓ | - | OLED displays correctly via I2C |
+| SWR-SYS-009 | System Information Display | ✓ | ✓ | ✓ | - | - | All required information displayed |
+| SWR-SYS-010 | Button-Based Menu Navigation | ✓ | ✓ | ✓ | - | - | Menu navigation works correctly |
+| SWR-SYS-011 | Local Diagnostic and Health Menus | ✓ | ✓ | ✓ | - | - | Diagnostic/health info accessible via menu |
+| SWR-SYS-012 | Diagnostic Session Support | ✓ | ✓ | ✓ | ✓ | - | Diagnostic sessions functional |
+| SWR-SYS-013 | Debug Session Support | ✓ | ✓ | ✓ | ✓ | - | Debug sessions functional |
+| SWR-SYS-014 | Authorized Debug Access Control | ✓ | ✓ | ✓ | ✓ | - | Unauthorized access rejected |
+| SWR-SYS-015 | Non-Intrusive Debug Sessions | ✓ | ✓ | ✓ | - | - | Debug sessions don't interfere with normal operation |
+
+### Data Acquisition Requirements
+
+| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
+|--------|-------------|----|----|-----|-----|------|---------------------|
+| SWR-DAQ-001 | Multi-Sensor Environmental Data Acquisition | ✓ | ✓ | ✓ | ✓ | - | All sensor types supported |
+| SWR-DAQ-002 | Dedicated Sensor Slot Mapping | ✓ | ✓ | ✓ | ✓ | - | Each sensor type mapped to unique slot |
+| SWR-DAQ-003 | Sensor Presence Detection | ✓ | ✓ | ✓ | - | - | Presence detection works correctly |
+| SWR-DAQ-004 | Conditional Sensor Initialization | ✓ | ✓ | ✓ | - | - | Only present sensors initialized |
+| SWR-DAQ-005 | High-Frequency Sensor Sampling | ✓ | ✓ | ✓ | ✓ | ✓ | 10 samples per cycle (default) |
+| SWR-DAQ-006 | Local Sensor Data Filtering | ✓ | ✓ | ✓ | ✓ | - | Filtering produces single value |
+| SWR-DAQ-007 | Deterministic Sampling Window | ✓ | ✓ | ✓ | ✓ | ✓ | Sampling completes within 100ms per sensor |
+| SWR-DAQ-008 | Timestamp Generation for Sensor Data | ✓ | ✓ | ✓ | - | - | Timestamps generated correctly |
+| SWR-DAQ-009 | Timestamped Sensor Data Record Structure | ✓ | ✓ | ✓ | ✓ | - | Record contains all required fields |
+| SWR-DAQ-010 | Availability of Latest Sensor Data | ✓ | ✓ | ✓ | - | - | Latest data available in memory |
+| SWR-DAQ-011 | State-Restricted Sensor Acquisition | ✓ | ✓ | ✓ | - | - | Acquisition blocked in OTA_UPDATE, MC_UPDATE, TEARDOWN |
+| SWR-DAQ-012 | Non-Blocking Sensor Acquisition | ✓ | ✓ | ✓ | ✓ | ✓ | No blocking operations in acquisition path |
+| SWR-DAQ-013 | Deterministic Memory Allocation | ✓ | ✓ | ✓ | ✓ | ✓ | No dynamic allocation in acquisition path |
+| SWR-DAQ-014 | Sensor Data Event Publishing | ✓ | ✓ | ✓ | - | - | Events published via Event System |
+| SWR-DAQ-015 | Failed Sensor Exclusion | ✓ | ✓ | ✓ | - | - | Failed sensors excluded from acquisition |
+
+### Data Quality & Calibration Requirements
+
+| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
+|--------|-------------|----|----|-----|-----|------|---------------------|
+| SWR-DQC-001 | Detect Sensor Presence | ✓ | ✓ | ✓ | - | - | Presence detection works correctly |
+| SWR-DQC-002 | Perform Sensor Detection During Initialization | ✓ | ✓ | ✓ | - | - | Detection performed during init |
+| SWR-DQC-003 | Conditional Sensor Initialization | ✓ | ✓ | ✓ | - | - | Only present sensors initialized |
+| SWR-DQC-004 | Assign Fixed Sensor Slot Types | ✓ | ✓ | ✓ | ✓ | - | Each slot assigned to sensor type |
+| SWR-DQC-005 | Verify Sensor Type Compatibility | ✓ | ✓ | ✓ | - | - | Sensor-slot compatibility verified |
+| SWR-DQC-006 | Reject Invalid Sensor Configurations | ✓ | ✓ | ✓ | - | - | Invalid configurations rejected and reported |
+| SWR-DQC-007 | Monitor Sensor Health | ✓ | ✓ | ✓ | - | - | Sensor health monitored continuously |
+| SWR-DQC-008 | Detect Sensor Failure Conditions | ✓ | ✓ | ✓ | - | - | All failure conditions detected |
+| SWR-DQC-009 | Isolate Failed Sensors | ✓ | ✓ | ✓ | - | - | Failed sensors marked and excluded |
+| SWR-DQC-010 | Report Sensor Failures | ✓ | ✓ | ✓ | - | - | Failures reported to Main Hub |
+| SWR-DQC-011 | Maintain Machine Constants Dataset | ✓ | ✓ | ✓ | ✓ | - | MC dataset maintained correctly |
+| SWR-DQC-012 | Persist Machine Constants | ✓ | ✓ | ✓ | - | - | MC persisted to non-volatile storage |
+| SWR-DQC-013 | Load Machine Constants at Startup | ✓ | ✓ | ✓ | - | - | MC loaded during initialization |
+| SWR-DQC-014 | Support Remote Machine Constants Update | ✓ | ✓ | ✓ | - | - | Remote MC updates supported |
+| SWR-DQC-015 | Controlled Reinitialization After Update | ✓ | ✓ | ✓ | - | - | Reinitialization after MC update |
+| SWR-DQC-016 | Machine Constants Integrity Validation | ✓ | ✓ | ✓ | ✓ | - | MC integrity validated before apply |
+| SWR-DQC-017 | State-Restricted Calibration | ✓ | ✓ | ✓ | - | - | Calibration blocked in OTA_UPDATE, MC_UPDATE, TEARDOWN |
+| SWR-DQC-018 | Machine Constants Access via DP | ✓ | ✓ | ✓ | ✓ | - | MC accessed only via DP component |
+
+### Communication Requirements
+
+| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
+|--------|-------------|----|----|-----|-----|------|---------------------|
+| SWR-COM-001 | Bidirectional Main Hub Communication | ✓ | ✓ | ✓ | ✓ | - | Bidirectional communication functional |
+| SWR-COM-002 | Transmit Data to Main Hub | ✓ | ✓ | ✓ | - | - | Sensor data, diagnostics, status transmitted |
+| SWR-COM-003 | Receive Commands from Main Hub | ✓ | ✓ | ✓ | - | - | Commands, config updates, OTA requests received |
+| SWR-COM-004 | Monitor Communication Link Status | ✓ | ✓ | ✓ | - | - | Link status monitored and reported |
+| SWR-COM-005 | Support On-Demand Data Requests | ✓ | ✓ | ✓ | - | - | On-demand requests supported |
+| SWR-COM-006 | Respond with Latest Sensor Data | ✓ | ✓ | ✓ | ✓ | ✓ | Response within 100ms with latest data |
+| SWR-COM-007 | Include Data Validity in Responses | ✓ | ✓ | ✓ | - | - | Validity status included in responses |
+| SWR-COM-008 | Support Peer Sensor Hub Communication | ✓ | ✓ | ✓ | - | - | Peer communication supported |
+| SWR-COM-009 | Isolate Peer Communication | ✓ | ✓ | ✓ | - | - | Peer communication doesn't interfere |
+| SWR-COM-010 | Encrypted Main Hub Communication | ✓ | ✓ | ✓ | ✓ | - | All communication encrypted |
+| SWR-COM-011 | Message Integrity and Authenticity | ✓ | ✓ | ✓ | ✓ | - | Message integrity and authenticity verified |
+| SWR-COM-012 | State-Restricted Communication | ✓ | ✓ | ✓ | - | - | Communication limited during TEARDOWN |
+| SWR-COM-013 | Non-Blocking Communication | ✓ | ✓ | ✓ | ✓ | ✓ | Communication operations non-blocking |
+| SWR-COM-014 | Communication Link Failure Reporting | ✓ | ✓ | ✓ | - | - | Link failures reported as diagnostics |
+| SWR-COM-015 | Security Violation Reporting | ✓ | ✓ | ✓ | - | - | Security violations reported to Main Hub |
+
+### Diagnostics Requirements
+
+| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
+|--------|-------------|----|----|-----|-----|------|---------------------|
+| SWR-DIAG-001 | Diagnostic Code Framework | ✓ | ✓ | ✓ | ✓ | - | Diagnostic framework implemented |
+| SWR-DIAG-002 | Assign Unique Diagnostic Codes | ✓ | ✓ | ✓ | ✓ | - | Each fault has unique code |
+| SWR-DIAG-003 | Classify Diagnostic Severity | ✓ | ✓ | ✓ | ✓ | - | Severity classification correct |
+| SWR-DIAG-004 | Timestamp and Source Diagnostics | ✓ | ✓ | ✓ | - | - | Timestamp and source associated |
+| SWR-DIAG-005 | Persist Diagnostic Events | ✓ | ✓ | ✓ | - | - | Diagnostic events persisted |
+| SWR-DIAG-006 | Retain Diagnostics Across Resets | ✓ | ✓ | ✓ | - | - | Diagnostics retained after reset |
+| SWR-DIAG-007 | Bounded Diagnostic Storage | ✓ | ✓ | ✓ | ✓ | - | Storage bounded with overwrite policy |
+| SWR-DIAG-008 | Provide Diagnostic Session Interface | ✓ | ✓ | ✓ | ✓ | - | Diagnostic session interface provided |
+| SWR-DIAG-009 | Retrieve Diagnostic Records | ✓ | ✓ | ✓ | - | - | Diagnostic records retrievable |
+| SWR-DIAG-010 | Clear Diagnostic Records | ✓ | ✓ | ✓ | - | - | Diagnostic records clearable |
+| SWR-DIAG-011 | Non-Intrusive Diagnostic Sessions | ✓ | ✓ | ✓ | - | - | Sessions don't interfere with operation |
+| SWR-DIAG-012 | Fault-to-State Transition | ✓ | ✓ | ✓ | - | - | Faults trigger state transitions |
+| SWR-DIAG-013 | Fault Latching Behavior | ✓ | ✓ | ✓ | - | - | Fault latching works correctly |
+| SWR-DIAG-014 | Fault Escalation Rules | ✓ | ✓ | ✓ | - | - | Escalation rules implemented |
+| SWR-DIAG-015 | Diagnostic Event Reporting to Main Hub | ✓ | ✓ | ✓ | - | - | WARNING/ERROR/FATAL events reported |
+| SWR-DIAG-016 | Diagnostic Information via HMI | ✓ | ✓ | ✓ | - | - | Diagnostic info accessible via HMI |
+| SWR-DIAG-017 | Diagnostic Storage Access via DP | ✓ | ✓ | ✓ | ✓ | - | Diagnostics accessed only via DP |
+| SWR-DIAG-018 | State-Restricted Diagnostic Generation | ✓ | ✓ | ✓ | - | - | Diagnostics limited during TEARDOWN |
+
+### Persistence Requirements
+
+| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
+|--------|-------------|----|----|-----|-----|------|---------------------|
+| SWR-DATA-001 | Persistent Timestamped Sensor Data | ✓ | ✓ | ✓ | - | - | Sensor data persisted correctly |
+| SWR-DATA-002 | Sensor Data Metadata Storage | ✓ | ✓ | ✓ | ✓ | - | Metadata stored with sensor data |
+| SWR-DATA-003 | Configurable Data Retention Policy | ✓ | ✓ | ✓ | ✓ | - | Retention policy configurable |
+| SWR-DATA-004 | Data Persistence Component Interface | ✓ | ✓ | ✓ | ✓ | - | DP component is sole interface |
+| SWR-DATA-005 | Storage Access Isolation | ✓ | ✓ | ✓ | ✓ | - | No direct storage access from application |
+| SWR-DATA-006 | Structured Data Serialization | ✓ | ✓ | ✓ | ✓ | - | Serialization/deserialization works |
+| SWR-DATA-007 | Data Flush Before Teardown | ✓ | ✓ | ✓ | ✓ | - | Critical data flushed before teardown |
+| SWR-DATA-008 | Data Integrity During Updates | ✓ | ✓ | ✓ | ✓ | - | Data integrity maintained during updates |
+| SWR-DATA-009 | Persistence Verification | ✓ | ✓ | ✓ | ✓ | - | Persistence verified before state transitions |
+| SWR-DATA-010 | State-Restricted Data Writes | ✓ | ✓ | ✓ | - | - | Writes restricted during TEARDOWN |
+| SWR-DATA-011 | Persistence Completion Confirmation | ✓ | ✓ | ✓ | - | - | Completion confirmed before transitions |
+| SWR-DATA-012 | SD Card Failure Handling | ✓ | ✓ | ✓ | - | - | SD failures handled gracefully |
+| SWR-DATA-013 | Wear-Aware Storage Management | ✓ | ✓ | ✓ | ✓ | - | Wear-aware management implemented |
+| SWR-DATA-014 | Single Source of Truth | ✓ | ✓ | ✓ | ✓ | - | Single source of truth maintained |
+| SWR-DATA-015 | No Private Persistent Copies | ✓ | ✓ | ✓ | ✓ | - | No private persistent copies |
+
+### OTA Requirements
+
+| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
+|--------|-------------|----|----|-----|-----|------|---------------------|
+| SWR-OTA-001 | OTA Negotiation Support | ✓ | ✓ | ✓ | - | - | OTA negotiation supported |
+| SWR-OTA-002 | OTA Readiness Validation | ✓ | ✓ | ✓ | - | - | Readiness validated before acceptance |
+| SWR-OTA-003 | OTA Acknowledgement | ✓ | ✓ | ✓ | - | - | OTA requests acknowledged/rejected |
+| SWR-OTA-004 | Firmware Reception | ✓ | ✓ | ✓ | - | - | Firmware received over communication |
+| SWR-OTA-005 | Firmware Temporary Storage | ✓ | ✓ | ✓ | - | - | Firmware stored in non-volatile storage |
+| SWR-OTA-006 | Active Firmware Protection | ✓ | ✓ | ✓ | ✓ | - | Active firmware not overwritten |
+| SWR-OTA-007 | Firmware Integrity Verification | ✓ | ✓ | ✓ | ✓ | - | Firmware integrity validated |
+| SWR-OTA-008 | Firmware Rejection Handling | ✓ | ✓ | ✓ | - | - | Invalid firmware rejected |
+| SWR-OTA-009 | OTA Status Reporting | ✓ | ✓ | ✓ | - | - | OTA status reported to Main Hub |
+| SWR-OTA-010 | OTA Teardown Execution | ✓ | ✓ | ✓ | - | - | Teardown executed before activation |
+| SWR-OTA-011 | Data Persistence Before Flashing | ✓ | ✓ | ✓ | - | - | Critical data persisted before flashing |
+| SWR-OTA-012 | Controlled Firmware Activation | ✓ | ✓ | ✓ | ✓ | - | Firmware activated only after validation |
+| SWR-OTA-013 | OTA Reboot Execution | ✓ | ✓ | ✓ | - | - | System reboots into new firmware |
+| SWR-OTA-014 | Encrypted OTA Communication | ✓ | ✓ | ✓ | ✓ | - | OTA communication encrypted |
+| SWR-OTA-015 | OTA State Transition | ✓ | ✓ | ✓ | - | - | Transitions to OTA_PREP on request |
+| SWR-OTA-016 | State-Restricted OTA Operations | ✓ | ✓ | ✓ | - | - | OTA blocked in WARNING/FAULT/SERVICE/SD_DEGRADED |
+| SWR-OTA-017 | OTA Duration Limit | ✓ | ✓ | ✓ | ✓ | ✓ | OTA completes within 10 minutes |
+| SWR-OTA-018 | OTA Failure Handling | ✓ | ✓ | ✓ | - | - | OTA failures trigger FAULT state |
+| SWR-OTA-019 | Active Firmware Corruption Protection | ✓ | ✓ | ✓ | ✓ | - | Active firmware protected during OTA |
+| SWR-OTA-020 | Firmware Authenticity Verification | ✓ | ✓ | ✓ | ✓ | - | Firmware authenticity verified |
+
+### Security Requirements
+
+| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
+|--------|-------------|----|----|-----|-----|------|---------------------|
+| SWR-SEC-001 | Firmware Authenticity Verification | ✓ | ✓ | ✓ | ✓ | - | Firmware verified on every boot |
+| SWR-SEC-002 | Unauthorized Firmware Blocking | ✓ | ✓ | ✓ | ✓ | - | Unauthorized firmware blocked |
+| SWR-SEC-003 | Secure Boot Failure Handling | ✓ | ✓ | ✓ | - | - | BOOT_FAILURE state on secure boot failure |
+| SWR-SEC-004 | Root-of-Trust Protection | ✓ | ✓ | ✓ | ✓ | - | Root-of-trust protected |
+| SWR-SEC-005 | Flash Data Access Protection | ✓ | ✓ | ✓ | ✓ | - | Flash data access protected |
+| SWR-SEC-006 | Encrypted External Storage | ✓ | ✓ | ✓ | ✓ | - | External storage encrypted |
+| SWR-SEC-007 | Cryptographic Key Isolation | ✓ | ✓ | ✓ | ✓ | - | Keys isolated to authorized components |
+| SWR-SEC-008 | Stored Data Integrity Assurance | ✓ | ✓ | ✓ | ✓ | - | Stored data integrity ensured |
+| SWR-SEC-009 | Encrypted Main Hub Communication | ✓ | ✓ | ✓ | ✓ | - | All communication encrypted |
+| SWR-SEC-010 | Message Integrity and Authenticity | ✓ | ✓ | ✓ | ✓ | - | Message integrity and authenticity verified |
+| SWR-SEC-011 | Secure OTA Data Transfer | ✓ | ✓ | ✓ | ✓ | - | OTA data transfer encrypted |
+| SWR-SEC-012 | Security Violation Reporting | ✓ | ✓ | ✓ | - | - | Security violations reported |
+| SWR-SEC-013 | Security First Initialization | ✓ | ✓ | ✓ | ✓ | - | Secure boot enabled before application |
+| SWR-SEC-014 | Debug Session Authentication | ✓ | ✓ | ✓ | ✓ | - | Debug sessions authenticated |
+| SWR-SEC-015 | Debug Security Bypass Prevention | ✓ | ✓ | ✓ | ✓ | - | Debug cannot bypass security |
+| SWR-SEC-016 | Security Violation Diagnostic Reporting | ✓ | ✓ | ✓ | - | - | Security violations reported as FATAL |
+| SWR-SEC-017 | Cryptographic Key Protection | ✓ | ✓ | ✓ | ✓ | - | Keys protected during power loss |
+| SWR-SEC-018 | Secure Session Establishment | ✓ | ✓ | ✓ | ✓ | - | Secure sessions established |
+| SWR-SEC-019 | Message Integrity Validation | ✓ | ✓ | ✓ | ✓ | - | Message integrity validated on receive |
+| SWR-SEC-020 | Downgrade Attack Prevention | ✓ | ✓ | ✓ | ✓ | - | Downgrade attacks prevented |
+
+### Performance Requirements
+
+| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
+|--------|-------------|----|----|-----|-----|------|---------------------|
+| SWR-PERF-001 | Sensor Acquisition Cycle Timing | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 100ms per sensor |
+| SWR-PERF-002 | State Transition Timing | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 50ms (except INIT, TEARDOWN) |
+| SWR-PERF-003 | Data Persistence Timing | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 200ms |
+| SWR-PERF-004 | OTA Operation Duration | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 10 minutes |
+| SWR-PERF-005 | CPU Utilization Limit | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 80% during normal operation |
+| SWR-PERF-006 | RAM Usage Limit | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 60% of available memory |
+| SWR-PERF-007 | Main Hub Response Time | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 100ms |
+| SWR-PERF-008 | Communication Link Failure Detection | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 30 seconds |
+
+## Test Coverage Summary
+
+- **Total SWRs:** 200+
+- **Unit Test Coverage:** ~180 SWRs (90%)
+- **Integration Test Coverage:** ~190 SWRs (95%)
+- **HIL Test Coverage:** ~150 SWRs (75%)
+- **Review Coverage:** ~100 SWRs (50%)
+- **Analysis Coverage:** ~30 SWRs (15%)
+
+## Traceability
+
+- **SRS Section 3:** All functional requirements covered
+- **Annex C:** Timing and resource budgets verified
+- **Component Specifications:** Component-level tests defined