<macro class="toc op-uc-placeholder op-uc-toc">
</macro>

# 8\. Firmware Update (OTA) Features

## 8.1 Feature Overview

The **Firmware Update (OTA) Features** enable the Sensor Hub (Sub-Hub) to safely receive, validate, and activate new firmware images provided by the Main Hub.  
These features ensure **controlled firmware lifecycle management**, **data integrity**, **system availability**, and **fault containment** during firmware update operations.

The OTA process is designed to:

*   Prevent unauthorized or corrupted firmware installation
    
*   Preserve critical system data and calibration information
    
*   Ensure recoverability in case of update failure
    
*   Minimize operational disruption
    

This feature set applies **only to the Sensor Hub (ESP32-S3 based)** and does not include cloud-side or Main Hub OTA logic.

## 8.2 Scope and Assumptions

### In Scope

*   OTA negotiation and readiness handshake with Main Hub
    
*   Firmware image reception over secure communication
    
*   Temporary firmware storage on SD card
    
*   Firmware integrity verification (e.g., CRC, hash)
    
*   Controlled firmware activation and reboot
    

### Out of Scope

*   Firmware generation and signing
    
*   Cloud-side firmware distribution
    
*   Rollback policy definition (may be extended later)
    

## 8.3 Sub-Features

### 8.3.1 F-OTA-01: OTA Update Negotiation

**Description**  
This sub-feature governs the initial negotiation phase between the Sensor Hub and the Main Hub prior to any firmware transfer.  
The Sensor Hub validates its current operational state and explicitly signals readiness before accepting an OTA update.

**Responsibilities**

*   Receive OTA availability notification
    
*   Validate system readiness (power, storage, state)
    
*   Acknowledge or reject OTA request
    
*   Transition system into OTA-preparation mode
    

### 8.3.2 F-OTA-02: Firmware Reception and Storage

**Description**  
This sub-feature handles the controlled reception of the firmware image from the Main Hub and its storage in non-volatile memory (SD card) without overwriting the currently running firmware.

**Responsibilities**

*   Receive firmware in chunks
    
*   Store firmware image on SD card
    
*   Monitor transfer completeness
    
*   Prevent execution during download
    

### 8.3.3 F-OTA-03: Firmware Integrity Validation

**Description**  
This sub-feature validates the integrity and correctness of the received firmware image prior to activation, ensuring that corrupted or incomplete firmware is never flashed.

**Responsibilities**

*   Perform integrity checks (CRC, checksum, hash)
    
*   Validate firmware size and metadata
    
*   Reject invalid firmware images
    
*   Report validation status to Main Hub
    

### 8.3.4 F-OTA-04: Safe Firmware Activation

**Description**  
This sub-feature manages the safe transition from the current firmware to the new firmware, ensuring all critical data is preserved and the system is left in a known safe state.

**Responsibilities**

*   Trigger teardown procedure
    
*   Persist runtime and calibration data
    
*   Flash validated firmware image
    
*   Reboot system into updated firmware
    

## 8.4 System Requirements (Formal SHALL Statements)

### OTA Negotiation Requirements

*   **SR-OTA-001**: The system shall support OTA update negotiation initiated by the Main Hub.
    
*   **SR-OTA-002**: The system shall verify internal readiness before accepting an OTA update request.
    
*   **SR-OTA-003**: The system shall explicitly acknowledge or reject OTA requests.
    

### Firmware Reception &amp; Storage Requirements

*   **SR-OTA-004**: The system shall receive firmware images over the established communication channel.
    
*   **SR-OTA-005**: The system shall store received firmware images in non-volatile storage prior to validation.
    
*   **SR-OTA-006**: The system shall prevent overwriting the active firmware during firmware reception.
    

### Firmware Integrity Requirements

*   **SR-OTA-007**: The system shall validate the integrity of the received firmware image before activation.
    
*   **SR-OTA-008**: The system shall reject firmware images that fail integrity validation.
    
*   **SR-OTA-009**: The system shall report firmware validation results to the Main Hub.
    

### Safe Activation Requirements

*   **SR-OTA-010**: The system shall execute a controlled teardown before firmware activation.
    
*   **SR-OTA-011**: The system shall persist critical runtime data prior to firmware flashing.
    
*   **SR-OTA-012**: The system shall activate new firmware only after successful validation.
    
*   **SR-OTA-013**: The system shall reboot into the new firmware following successful activation.
    

## 8.5 Feature-to-Requirement Traceability

<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><thead class="op-uc-table--head"><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Feature ID</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Related System Requirements</p></th></tr></thead><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">F-OTA-01</p></td><td class="op-uc-table--cell"><p class="op-uc-p">SR-OTA-001, SR-OTA-002, SR-OTA-003</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">F-OTA-02</p></td><td class="op-uc-table--cell"><p class="op-uc-p">SR-OTA-004, SR-OTA-005, SR-OTA-006</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">F-OTA-03</p></td><td class="op-uc-table--cell"><p class="op-uc-p">SR-OTA-007, SR-OTA-008, SR-OTA-009</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">F-OTA-04</p></td><td class="op-uc-table--cell"><p class="op-uc-p">SR-OTA-010, SR-OTA-011, SR-OTA-012, SR-OTA-013</p></td></tr></tbody></table></figure>

## 8.6 Architectural Considerations (Informative)

*   OTA logic shall be implemented as a **dedicated OTA Manager component**
    
*   Firmware storage shall be accessed via the **DP (Data Persistence) component**
    
*   OTA state transitions shall interact with:
    
    *   Diagnostics subsystem
        
    *   Machine Constants management
        
    *   Teardown mechanism
        
*   OTA execution shall not block critical system diagnostics reporting
    

## 8.7 Related Features

*   **Persistence &amp; Data Management Features (F-DATA-03)**
    
*   **Diagnostics &amp; Health Monitoring Features**
    
*   **Security &amp; Safety Features (Secure Boot, Secure Flash)**
    

###