update

2026-01-26 12:43:14 +01:00
parent c631110349
commit bedcd373f5
133 changed files with 37347 additions and 29 deletions
--- a/Design/draft/Features_old/[OTA]
+++ b/Design/draft/Features_old/[OTA]
@@ -0,0 +1,185 @@
+<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)**
+    
+
+###