845 lines
31 KiB
Markdown
845 lines
31 KiB
Markdown
# 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`)
|