1453 lines
56 KiB
Markdown
1453 lines
56 KiB
Markdown
# Software Requirements Specification (SRS)
|
|
# ASF Sensor Hub (Sub-Hub) Embedded System
|
|
|
|
**Document ID:** SRS-ASF-SensorHub-SW-001
|
|
**Version:** 2.0
|
|
**Date:** 2025-02-01
|
|
**Standard:** ISO/IEC/IEEE 29148:2018
|
|
**Scope:** Software Requirements for ASF Sensor Hub (Sub-Hub)
|
|
**Platform:** ESP32-S3, ESP-IDF v5.4, C/C++
|
|
**Domain:** Industrial/Agricultural Automation (Smart Poultry Farm)
|
|
|
|
## 1. Introduction
|
|
|
|
### 1.1 Purpose
|
|
|
|
This Software Requirements Specification (SRS) defines the complete set of software requirements for the ASF Sensor Hub (Sub-Hub) embedded system. This document serves as the authoritative source for all functional and non-functional software requirements that must be satisfied by the implementation.
|
|
|
|
### 1.2 Scope
|
|
|
|
The ASF Sensor Hub software is responsible for:
|
|
|
|
- **Sensor Data Acquisition:** Multi-sensor environmental monitoring with local preprocessing
|
|
- **Data Quality & Calibration:** Sensor validation, failure detection, and calibration management
|
|
- **Communication:** Secure bidirectional communication with Main Hub and peer coordination
|
|
- **Diagnostics & Health Monitoring:** Comprehensive system health monitoring and fault management
|
|
- **Persistence & Data Management:** Reliable data storage with integrity protection
|
|
- **Firmware Update (OTA):** Secure over-the-air firmware updates with rollback capability
|
|
- **Security & Safety:** Hardware-enforced security with encrypted communication
|
|
- **System Management:** State machine control, teardown coordination, and local HMI
|
|
- **Power & Fault Handling:** Graceful degradation and recovery mechanisms
|
|
- **Hardware Abstraction:** Platform-independent sensor and peripheral interfaces
|
|
|
|
**Explicitly out of scope:**
|
|
- Main Hub processing and control logic
|
|
- Cloud analytics and services
|
|
- Farm control algorithms and actuator management
|
|
- Hardware design specifications
|
|
|
|
### 1.3 Definitions and Acronyms
|
|
|
|
| Term | Definition |
|
|
|------|------------|
|
|
| **SWR** | Software Requirement (unique identifier format: SWR-XXX-NNN) |
|
|
| **SR** | System Requirement (from system design documents) |
|
|
| **Sub-Hub** | The ASF Sensor Hub embedded system (this system) |
|
|
| **Main Hub** | Central processing unit that coordinates multiple Sub-Hubs |
|
|
| **MC** | Machine Constants - persistent configuration and calibration data |
|
|
| **DP** | Data Persistence component - sole interface for persistent storage |
|
|
| **STM** | State Manager component - system state machine controller |
|
|
| **SAL** | Sensor Abstraction Layer - uniform sensor interface |
|
|
| **HMI** | Human-Machine Interface (OLED display + navigation buttons) |
|
|
| **OTA** | Over-The-Air firmware update mechanism |
|
|
| **mTLS** | Mutual Transport Layer Security |
|
|
| **CBOR** | Concise Binary Object Representation |
|
|
| **ESP-NOW** | ESP32 proprietary peer-to-peer communication protocol |
|
|
|
|
### 1.4 References
|
|
|
|
- **System Requirements:** `0 system_design/SRS/SRS.md`
|
|
- **System Features:** `0 system_design/features/Features.md`
|
|
- **Cross-Feature Constraints:** `0 system_design/features/Cross-Feature Constraints.md`
|
|
- **System State Machine:** `0 system_design/specifications/System_State_Machine_Specification.md`
|
|
- **Failure Handling Model:** `0 system_design/specifications/Failure_Handling_Model.md`
|
|
- **ISO/IEC/IEEE 29148:2018** - Requirements engineering standard
|
|
- **IEC 61508** - Functional safety standard
|
|
- **ESP-IDF v5.4 Programming Guide**
|
|
|
|
### 1.5 Document Organization
|
|
|
|
This SRS is organized as follows:
|
|
- **Section 2:** Overall Description (product perspective, functions, constraints)
|
|
- **Section 3:** Software Requirements (functional, interface, performance, design, quality)
|
|
- **Section 4:** Traceability (SR → SWR mapping)
|
|
- **Section 5:** Verification Methods
|
|
|
|
## 2. Overall Description
|
|
|
|
### 2.1 Product Perspective
|
|
|
|
The ASF Sensor Hub software operates on ESP32-S3 hardware within a distributed poultry farm automation network. The software interfaces with:
|
|
|
|
- **Environmental sensors** via I2C, SPI, UART, and analog interfaces
|
|
- **Main Hub** via encrypted Wi-Fi communication (MQTT over TLS 1.2)
|
|
- **Peer Sub-Hubs** via ESP-NOW for limited coordination
|
|
- **Local operators** via OLED display and button interface
|
|
- **SD Card** for persistent data storage
|
|
- **Internal NVM** for configuration and security data
|
|
|
|
### 2.2 Product Functions
|
|
|
|
The software provides the following major functions organized by feature groups:
|
|
|
|
#### 2.2.1 Sensor Data Acquisition (DAQ)
|
|
- Multi-sensor simultaneous data acquisition
|
|
- High-frequency sampling with local filtering
|
|
- Timestamped sensor data generation
|
|
- Sensor state management and validation
|
|
|
|
#### 2.2.2 Data Quality & Calibration (DQC)
|
|
- Automatic sensor detection and type enforcement
|
|
- Sensor failure detection and classification
|
|
- Machine Constants management and application
|
|
- Calibration parameter handling
|
|
|
|
#### 2.2.3 Communication (COM)
|
|
- Main Hub bidirectional communication
|
|
- On-demand data broadcasting
|
|
- Peer Sensor Hub coordination
|
|
- Communication fault tolerance
|
|
|
|
#### 2.2.4 Diagnostics & Health Monitoring (DIAG)
|
|
- Structured diagnostic code management
|
|
- Persistent diagnostic data storage
|
|
- Diagnostic session support
|
|
- Layered watchdog system
|
|
|
|
#### 2.2.5 Persistence & Data Management (DATA)
|
|
- Persistent sensor data storage
|
|
- Data persistence abstraction (DP component)
|
|
- Safe data handling during state transitions
|
|
- Storage capacity and wear management
|
|
|
|
#### 2.2.6 Firmware Update (OTA)
|
|
- OTA update negotiation and coordination
|
|
- Firmware reception and integrity validation
|
|
- Safe firmware activation with rollback
|
|
- OTA state management
|
|
|
|
#### 2.2.7 Security & Safety (SEC)
|
|
- Secure boot and flash encryption
|
|
- Certificate management and validation
|
|
- Encrypted communication channels
|
|
- Security violation detection and response
|
|
|
|
#### 2.2.8 System Management (SYS)
|
|
- System state machine implementation
|
|
- Controlled teardown mechanism
|
|
- Local human-machine interface
|
|
- Engineering access and debug sessions
|
|
|
|
#### 2.2.9 Power & Fault Handling (PWR)
|
|
- Brownout detection and recovery
|
|
- Fault classification and escalation
|
|
- Graceful degradation mechanisms
|
|
|
|
#### 2.2.10 Hardware Abstraction (HW)
|
|
- Sensor abstraction layer
|
|
- Hardware interface abstraction
|
|
- GPIO discipline and resource management
|
|
|
|
### 2.3 User Classes and Characteristics
|
|
|
|
| User Class | Characteristics | Software Interaction |
|
|
|------------|-----------------|---------------------|
|
|
| **Farm Operators** | Basic technical knowledge, daily monitoring | Local HMI for status checking and basic diagnostics |
|
|
| **Maintenance Engineers** | Advanced technical knowledge, periodic maintenance | Debug sessions, diagnostic data access, system health monitoring |
|
|
| **System Integrators** | Expert technical knowledge, system configuration | Machine constants management, OTA updates, engineering access |
|
|
| **Main Hub System** | Automated system, continuous operation | Bidirectional communication, data requests, control commands |
|
|
|
|
### 2.4 Operating Environment
|
|
|
|
#### 2.4.1 Hardware Environment
|
|
- **Microcontroller:** ESP32-S3 (dual-core, 512KB SRAM, 8MB Flash)
|
|
- **Sensors:** I2C, SPI, UART, and analog environmental sensors
|
|
- **Storage:** SD Card (FAT32), Internal NVM (encrypted)
|
|
- **Display:** OLED 128x64 pixels (I2C interface)
|
|
- **Input:** 3x GPIO buttons (Up, Down, Select)
|
|
- **Communication:** Wi-Fi 802.11n (2.4 GHz), ESP-NOW
|
|
|
|
#### 2.4.2 Software Environment
|
|
- **Operating System:** FreeRTOS (via ESP-IDF framework)
|
|
- **Development Framework:** ESP-IDF v5.4
|
|
- **Programming Language:** C/C++ (MISRA C:2012 compliant)
|
|
- **Security:** Secure Boot V2, Flash Encryption (AES-256)
|
|
- **Communication:** MQTT over TLS 1.2, CBOR encoding
|
|
|
|
#### 2.4.3 Physical Environment
|
|
- **Location:** Industrial poultry house environment
|
|
- **Temperature:** -10°C to +60°C operating range
|
|
- **Humidity:** Up to 95% relative humidity
|
|
- **Contaminants:** Dust, ammonia, organic particles
|
|
- **Power:** 12V DC with brownout protection
|
|
- **Enclosure:** IP65 rated protection
|
|
|
|
### 2.5 Design and Implementation Constraints
|
|
|
|
#### 2.5.1 Hardware Constraints
|
|
- **Memory:** 512KB SRAM, 8MB Flash (ESP32-S3 limitations)
|
|
- **Processing:** Dual-core 240MHz (shared with ESP-IDF framework)
|
|
- **I/O:** Limited GPIO pins for sensors and peripherals
|
|
- **Storage:** SD card subject to wear and environmental failure
|
|
- **Power:** Continuous AC power with brief interruption tolerance
|
|
|
|
#### 2.5.2 Software Constraints
|
|
- **Framework:** ESP-IDF v5.4 mandatory (platform dependency)
|
|
- **Real-time:** FreeRTOS task scheduling with deterministic timing
|
|
- **Memory Management:** Static allocation preferred, minimal dynamic allocation
|
|
- **Security:** Hardware-enforced Secure Boot V2 and Flash Encryption
|
|
- **Communication:** TLS 1.2 mandatory for all external communication
|
|
|
|
#### 2.5.3 Regulatory Constraints
|
|
- **Safety:** IEC 61508 SIL-1 compliance for sensor data integrity
|
|
- **Security:** Encrypted storage and communication mandatory
|
|
- **Environmental:** Animal welfare regulations compliance
|
|
- **Electromagnetic:** CE/FCC compliance for wireless communication
|
|
|
|
#### 2.5.4 Operational Constraints
|
|
- **Availability:** 99.9% uptime requirement in normal conditions
|
|
- **Maintenance:** Unattended operation (24/7) with remote diagnostics
|
|
- **Updates:** OTA firmware updates with minimal downtime
|
|
- **Recovery:** Automatic recovery from transient faults within 30 seconds
|
|
|
|
### 2.6 Assumptions and Dependencies
|
|
|
|
#### 2.6.1 Assumptions
|
|
- **Sensors:** Pre-configured and compatible with defined interfaces
|
|
- **Time Synchronization:** Main Hub provides accurate time reference
|
|
- **Cryptographic Keys:** Securely provisioned during manufacturing
|
|
- **Power:** Brief interruptions (< 1 second) are acceptable
|
|
- **Network:** Wi-Fi infrastructure available and stable
|
|
- **Storage:** SD card properly formatted and functional
|
|
|
|
#### 2.6.2 Dependencies
|
|
- **ESP-IDF Framework:** Version 5.4 availability and stability
|
|
- **Sensor Drivers:** Compatible drivers for all supported sensor types
|
|
- **Main Hub Protocol:** Communication protocol compatibility
|
|
- **Certificate Authority:** PKI infrastructure for certificate management
|
|
- **Time Source:** NTP or Main Hub time synchronization
|
|
|
|
## 3. Software Requirements
|
|
|
|
### 3.1 Functional Requirements
|
|
|
|
#### 3.1.1 System State Management (SWR-SYS-001 through SWR-SYS-020)
|
|
|
|
**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
|
|
**Verification:** Test, Inspection
|
|
|
|
**SWR-SYS-002:** The software SHALL enforce valid state transitions as defined in the System State Machine Specification and reject invalid transition requests.
|
|
|
|
**Traceability:** SR-SYS-001
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-003:** The software SHALL restrict feature operations based on the current system state according to per-state execution rules defined in Cross-Feature Constraints.
|
|
|
|
**Traceability:** SR-SYS-002, CFC-ARCH-02
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-004:** The software SHALL notify all registered components when a state transition occurs via the Event System within 10ms of transition completion.
|
|
|
|
**Traceability:** SR-SYS-003
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-005:** The software SHALL execute a controlled teardown sequence before firmware updates, machine constant updates, or system resets.
|
|
|
|
**Traceability:** SR-SYS-004
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-006:** The software SHALL persist all critical runtime data before completing a teardown sequence and verify persistence completion.
|
|
|
|
**Traceability:** SR-SYS-005, CFC-DATA-02
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-007:** The software SHALL prevent data corruption during teardown and reset operations by completing all pending write operations.
|
|
|
|
**Traceability:** SR-SYS-006
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-008:** The software SHALL provide a local OLED display interface using I2C communication protocol with 128x64 pixel resolution.
|
|
|
|
**Traceability:** SR-SYS-007
|
|
**Verification:** Test, Demonstration
|
|
|
|
**SWR-SYS-009:** The software SHALL display connectivity status, system state, connected sensor summary, and current time/date on the OLED display with automatic refresh every 5 seconds.
|
|
|
|
**Traceability:** SR-SYS-008
|
|
**Verification:** Test, Demonstration
|
|
|
|
**SWR-SYS-010:** The software SHALL provide menu navigation using Up, Down, and Select buttons with debouncing and repeat functionality.
|
|
|
|
**Traceability:** SR-SYS-009
|
|
**Verification:** Test, Demonstration
|
|
|
|
**SWR-SYS-011:** The software SHALL provide diagnostic, sensor status, and system health information through the local OLED menu interface with hierarchical navigation.
|
|
|
|
**Traceability:** SR-SYS-010
|
|
**Verification:** Test, Demonstration
|
|
|
|
**SWR-SYS-012:** The software SHALL support diagnostic sessions for retrieving system status, diagnostic data, and configuration information via authenticated access.
|
|
|
|
**Traceability:** SR-SYS-011
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-013:** The software SHALL support debug sessions allowing controlled engineering commands with authentication and authorization checks.
|
|
|
|
**Traceability:** SR-SYS-012
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-014:** The software SHALL restrict debug session actions to authorized engineering access only using certificate-based authentication.
|
|
|
|
**Traceability:** SR-SYS-013, CFC-DBG-01
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-016:** The software SHALL implement state transition timeouts to prevent indefinite blocking in intermediate states.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-017:** The software SHALL log all state transitions with timestamps and transition reasons for diagnostic purposes.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-018:** The software SHALL validate state transition preconditions before executing transitions and reject invalid requests.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-019:** The software SHALL provide state query interfaces for components to check current state and transition validity.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-SYS-020:** The software SHALL coordinate teardown sequence with all active components and wait for completion acknowledgments.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
#### 3.1.2 Sensor Data Acquisition (SWR-DAQ-001 through SWR-DAQ-020)
|
|
|
|
**SWR-DAQ-001:** The software SHALL support simultaneous acquisition of environmental data from multiple sensor types: temperature, humidity, CO2, NH3, VOC, particulate matter, and light intensity.
|
|
|
|
**Traceability:** SR-DAQ-001
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-002:** The software SHALL assign each supported sensor type to a predefined and unique hardware slot with dedicated GPIO and communication interface.
|
|
|
|
**Traceability:** SR-DAQ-002
|
|
**Verification:** Inspection, Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-004:** The software SHALL initialize and activate only sensors that are detected as present and enabled in Machine Constants configuration.
|
|
|
|
**Traceability:** SR-DAQ-004
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-005:** The software SHALL sample each enabled sensor multiple times within a single acquisition cycle (configurable, default: 10 samples per sensor per cycle).
|
|
|
|
**Traceability:** SR-DAQ-005
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-006:** The software SHALL apply a configurable local filtering mechanism (median filter, moving average) to raw sensor samples to produce a single filtered sensor value per acquisition cycle.
|
|
|
|
**Traceability:** SR-DAQ-006
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-008:** The software SHALL generate a timestamp for each filtered sensor value upon completion of the acquisition and filtering process using system time.
|
|
|
|
**Traceability:** SR-DAQ-008
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-009:** The software SHALL generate a timestamped sensor data record containing: sensor identifier, sensor type, filtered value, unit of measurement, timestamp, and data validity status.
|
|
|
|
**Traceability:** SR-DAQ-009
|
|
**Verification:** Test, Inspection
|
|
|
|
**SWR-DAQ-010:** The software SHALL maintain the most recent timestamped sensor data record in memory (Data Pool) and make it available for persistence and communication requests.
|
|
|
|
**Traceability:** SR-DAQ-010
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-011:** The software SHALL NOT perform sensor acquisition during OTA_UPDATE, MC_UPDATE, or TEARDOWN states.
|
|
|
|
**Traceability:** CFC-ARCH-02
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-012:** The software SHALL perform sensor acquisition in a non-blocking manner using task-based scheduling.
|
|
|
|
**Traceability:** CFC-TIME-01
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-013:** The software SHALL use deterministic memory allocation for sensor acquisition buffers (no dynamic allocation in acquisition path).
|
|
|
|
**Traceability:** CFC-TIME-02
|
|
**Verification:** Inspection, Test
|
|
|
|
**SWR-DAQ-014:** The software SHALL publish sensor data updates via the Event System upon completion of each acquisition cycle.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-015:** The software SHALL exclude failed sensors from acquisition cycles as defined by the failure handling model.
|
|
|
|
**Traceability:** SR-DQC-009
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-016:** The software SHALL implement sensor warmup periods before considering sensor data valid (configurable per sensor type).
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-017:** The software SHALL validate sensor readings against configured range limits and mark out-of-range values as invalid.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-018:** The software SHALL implement acquisition cycle scheduling with configurable intervals (default: 1 second).
|
|
|
|
**Traceability:** Performance requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-019:** The software SHALL provide sensor status information including presence, health, last reading time, and error counts.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DAQ-020:** The software SHALL implement sensor driver abstraction layer (SAL) providing uniform interfaces for different sensor types.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Inspection
|
|
|
|
#### 3.1.3 Data Quality & Calibration (SWR-DQC-001 through SWR-DQC-020)
|
|
|
|
**SWR-DQC-001:** The software SHALL detect the physical presence of each sensor using a dedicated hardware-based detection mechanism during system initialization.
|
|
|
|
**Traceability:** SR-DQC-001
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-002:** The software SHALL perform sensor presence detection during system startup and after any reinitialization or reconfiguration event.
|
|
|
|
**Traceability:** SR-DQC-002
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-003:** The software SHALL initialize and activate only sensors that are detected as present and match the expected sensor type.
|
|
|
|
**Traceability:** SR-DQC-003
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-004:** The software SHALL assign each physical sensor slot to a predefined sensor type as defined in Machine Constants configuration.
|
|
|
|
**Traceability:** SR-DQC-004
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-005:** The software SHALL verify that a detected sensor matches the expected sensor type for its assigned slot using sensor identification mechanisms.
|
|
|
|
**Traceability:** SR-DQC-005
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-006:** The software SHALL reject and report any sensor-slot mismatch as a diagnostic event with ERROR severity.
|
|
|
|
**Traceability:** SR-DQC-006
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-007:** The software SHALL continuously monitor sensor responsiveness and signal validity during normal operation.
|
|
|
|
**Traceability:** SR-DQC-007
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-008:** The software SHALL detect sensor failures including disconnection, non-responsiveness, and out-of-range measurement values.
|
|
|
|
**Traceability:** SR-DQC-008
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-009:** The software SHALL mark detected faulty sensors as defective and exclude them from data acquisition and reporting.
|
|
|
|
**Traceability:** SR-DQC-009
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-010:** The software SHALL report detected sensor failures to the Main Hub with timestamps and failure classification.
|
|
|
|
**Traceability:** SR-DQC-010
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-011:** The software SHALL maintain a Machine Constants dataset defining sensor configuration, calibration parameters, and communication identifiers.
|
|
|
|
**Traceability:** SR-DQC-011
|
|
**Verification:** Test, Inspection
|
|
|
|
**SWR-DQC-012:** The software SHALL store the Machine Constants dataset in non-volatile storage with integrity protection.
|
|
|
|
**Traceability:** SR-DQC-012
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-013:** The software SHALL load and apply the Machine Constants dataset during system initialization and validate data integrity.
|
|
|
|
**Traceability:** SR-DQC-013
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-014:** The software SHALL support remote updates of the Machine Constants dataset initiated by the Main Hub with authentication.
|
|
|
|
**Traceability:** SR-DQC-014
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-015:** The software SHALL apply updated Machine Constants only after executing a controlled teardown and reinitialization procedure.
|
|
|
|
**Traceability:** SR-DQC-015
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-016:** The software SHALL validate Machine Constants integrity using checksums before applying updates.
|
|
|
|
**Traceability:** SR-SEC-008
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-017:** The software SHALL NOT perform sensor calibration during OTA_UPDATE, MC_UPDATE, or TEARDOWN states.
|
|
|
|
**Traceability:** CFC-ARCH-02
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-018:** The software SHALL access Machine Constants only through the DP component interface.
|
|
|
|
**Traceability:** CFC-ARCH-01, CFC-DATA-01
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DQC-019:** The software SHALL apply calibration parameters to raw sensor readings to produce calibrated values.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DQC-020:** The software SHALL maintain sensor failure statistics and report trends to diagnostic system.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
#### 3.1.4 Communication (SWR-COM-001 through SWR-COM-020)
|
|
|
|
**SWR-COM-001:** The software SHALL support bidirectional communication between the Sensor Hub and the Main Hub using MQTT over TLS 1.2.
|
|
|
|
**Traceability:** SR-COM-001
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-002:** The software SHALL transmit sensor data, diagnostics information, and system status to the Main Hub using CBOR encoding.
|
|
|
|
**Traceability:** SR-COM-002
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-003:** The software SHALL receive commands, configuration updates, and firmware update requests from the Main Hub.
|
|
|
|
**Traceability:** SR-COM-003
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-005:** The software SHALL support on-demand requests from the Main Hub for sensor data with response time ≤ 100ms.
|
|
|
|
**Traceability:** SR-COM-005
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-006:** The software SHALL respond to on-demand data requests with the most recent timestamped sensor data from the Data Pool.
|
|
|
|
**Traceability:** SR-COM-006
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-007:** The software SHALL include sensor status and data validity information in on-demand data responses.
|
|
|
|
**Traceability:** SR-COM-007
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-008:** The software SHALL support limited peer-to-peer communication between Sensor Hubs using ESP-NOW for connectivity checks and time synchronization.
|
|
|
|
**Traceability:** SR-COM-008, SR-COM-009
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-010:** The software SHALL encrypt all communication with the Main Hub using TLS 1.2 with mutual authentication.
|
|
|
|
**Traceability:** SR-SEC-009, CFC-SEC-02
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-011:** The software SHALL ensure integrity and authenticity of all transmitted and received messages using message authentication codes.
|
|
|
|
**Traceability:** SR-SEC-010
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-012:** The software SHALL limit communication operations during TEARDOWN state to session closure only.
|
|
|
|
**Traceability:** CFC-ARCH-02
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-013:** The software SHALL perform communication operations in a non-blocking manner using task-based scheduling.
|
|
|
|
**Traceability:** CFC-TIME-01
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-015:** The software SHALL detect and report communication security violations to the Main Hub and diagnostic system.
|
|
|
|
**Traceability:** SR-SEC-012
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-016:** The software SHALL implement heartbeat mechanism with 10-second interval and 30-second timeout detection.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-017:** The software SHALL support automatic reconnection with exponential backoff on communication link failure.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-018:** The software SHALL encrypt ESP-NOW peer communication using application-layer encryption (AES-128 minimum).
|
|
|
|
**Traceability:** Security requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-019:** The software SHALL implement message queuing for store-and-forward capability during communication outages.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-COM-020:** The software SHALL validate message format and version compatibility for all received messages.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
*[Continue with remaining sections...]*
|
|
#### 3.1.5 Diagnostics & Health Monitoring (SWR-DIAG-001 through SWR-DIAG-020)
|
|
|
|
**SWR-DIAG-001:** The software SHALL implement a diagnostic code framework for reporting system health conditions, warnings, errors, and fatal faults with unique identifiers.
|
|
|
|
**Traceability:** SR-DIAG-001
|
|
**Verification:** Test, Inspection
|
|
|
|
**SWR-DIAG-002:** The software SHALL assign a unique diagnostic code to each detected fault or abnormal condition using format 0xSCCC (S=severity, CCC=code).
|
|
|
|
**Traceability:** SR-DIAG-002
|
|
**Verification:** Test, Inspection
|
|
|
|
**SWR-DIAG-003:** The software SHALL classify diagnostic codes by severity level (INFO, WARNING, ERROR, FATAL) with defined escalation rules.
|
|
|
|
**Traceability:** SR-DIAG-003
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-004:** The software SHALL associate each diagnostic event with a timestamp and the originating system component identifier.
|
|
|
|
**Traceability:** SR-DIAG-004
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-005:** The software SHALL persist diagnostic events in non-volatile storage through the DP component interface.
|
|
|
|
**Traceability:** SR-DIAG-005
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-006:** The software SHALL retain diagnostic data across system resets and power cycles with data integrity protection.
|
|
|
|
**Traceability:** SR-DIAG-006
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-007:** The software SHALL implement a bounded diagnostic storage mechanism with circular buffer and configurable retention policy.
|
|
|
|
**Traceability:** SR-DIAG-007
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-008:** The software SHALL provide a diagnostic session interface for accessing diagnostic and system health data via authenticated access.
|
|
|
|
**Traceability:** SR-DIAG-008
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-009:** The software SHALL allow authorized diagnostic sessions to retrieve stored diagnostic events with filtering capabilities.
|
|
|
|
**Traceability:** SR-DIAG-009
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-010:** The software SHALL allow authorized diagnostic sessions to clear stored diagnostic records with confirmation.
|
|
|
|
**Traceability:** SR-DIAG-010
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-013:** The software SHALL implement fault latching behavior as defined in the failure handling model.
|
|
|
|
**Traceability:** Failure Handling Model
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-014:** The software SHALL implement fault escalation rules as defined in the failure handling model.
|
|
|
|
**Traceability:** Failure Handling Model
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-015:** The software SHALL report WARNING, ERROR, and FATAL diagnostic events to the Main Hub within 5 seconds of detection.
|
|
|
|
**Traceability:** SR-COM-002
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-016:** The software SHALL provide diagnostic information through the local OLED menu interface with hierarchical display.
|
|
|
|
**Traceability:** SR-SYS-010
|
|
**Verification:** Test, Demonstration
|
|
|
|
**SWR-DIAG-017:** The software SHALL access diagnostic storage only through the DP component interface.
|
|
|
|
**Traceability:** CFC-ARCH-01, CFC-DATA-01
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DIAG-018:** The software SHALL NOT generate new diagnostic events during TEARDOWN state (except teardown-specific diagnostics).
|
|
|
|
**Traceability:** CFC-ARCH-02
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-019:** The software SHALL implement watchdog mechanisms at task, interrupt, and system levels with configurable timeouts.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DIAG-020:** The software SHALL provide diagnostic event statistics and trending information for system health assessment.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
#### 3.1.6 Persistence & Data Management (SWR-DATA-001 through SWR-DATA-020)
|
|
|
|
**SWR-DATA-001:** The software SHALL persist timestamped sensor data in non-volatile storage using wear-aware batch writing.
|
|
|
|
**Traceability:** SR-DATA-001
|
|
**Verification:** Test
|
|
|
|
**SWR-DATA-002:** The software SHALL store sensor data together with sensor identifiers, timestamps, and validity status in structured format.
|
|
|
|
**Traceability:** SR-DATA-002
|
|
**Verification:** Test
|
|
|
|
**SWR-DATA-003:** The software SHALL support configurable data retention and overwrite policies for persisted sensor data.
|
|
|
|
**Traceability:** SR-DATA-003
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DATA-005:** The software SHALL prevent application and feature modules from directly accessing storage hardware.
|
|
|
|
**Traceability:** SR-DATA-005, CFC-ARCH-01
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DATA-006:** The DP component SHALL support serialization and deserialization of structured system data using defined formats.
|
|
|
|
**Traceability:** SR-DATA-006
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-DATA-008:** The software SHALL protect data integrity during firmware updates and machine constant updates using atomic operations.
|
|
|
|
**Traceability:** SR-DATA-008
|
|
**Verification:** Test
|
|
|
|
**SWR-DATA-009:** The software SHALL verify successful data persistence before completing a system state transition.
|
|
|
|
**Traceability:** SR-DATA-009, CFC-DATA-02
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-DATA-011:** The software SHALL ensure persistence completion is confirmed before state transitions that require data consistency.
|
|
|
|
**Traceability:** CFC-DATA-02
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-DATA-013:** The software SHALL implement wear-aware storage management to prevent premature SD card failure.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DATA-015:** The software SHALL NOT allow features to maintain private persistent copies of shared system data.
|
|
|
|
**Traceability:** CFC-DATA-01
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DATA-016:** The software SHALL implement data integrity checks using checksums for all persistent data.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DATA-017:** The software SHALL support data backup and recovery mechanisms for critical system data.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DATA-018:** The software SHALL implement storage capacity monitoring and alert when storage space is low.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DATA-019:** The software SHALL support data export functionality for diagnostic and maintenance purposes.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-DATA-020:** The software SHALL implement secure deletion of sensitive data when required.
|
|
|
|
**Traceability:** Security requirement
|
|
**Verification:** Test
|
|
|
|
#### 3.1.7 Firmware Update (OTA) (SWR-OTA-001 through SWR-OTA-025)
|
|
|
|
**SWR-OTA-001:** The software SHALL support OTA update negotiation initiated by the Main Hub with capability verification.
|
|
|
|
**Traceability:** SR-OTA-001
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-002:** The software SHALL verify internal readiness conditions before accepting an OTA update request.
|
|
|
|
**Traceability:** SR-OTA-002
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-003:** The software SHALL explicitly acknowledge or reject OTA update requests with reason codes.
|
|
|
|
**Traceability:** SR-OTA-003
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-004:** The software SHALL receive firmware images over the established communication interface with progress reporting.
|
|
|
|
**Traceability:** SR-OTA-004
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-005:** The software SHALL store received firmware images in non-volatile storage prior to validation.
|
|
|
|
**Traceability:** SR-OTA-005
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-006:** The software SHALL prevent overwriting the active firmware during firmware reception using A/B partitioning.
|
|
|
|
**Traceability:** SR-OTA-006
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-007:** The software SHALL validate the integrity of received firmware images using SHA-256 checksums before activation.
|
|
|
|
**Traceability:** SR-OTA-007
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-008:** The software SHALL reject firmware images that fail integrity validation and report failure reason.
|
|
|
|
**Traceability:** SR-OTA-008
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-009:** The software SHALL report firmware validation and OTA status to the Main Hub throughout the process.
|
|
|
|
**Traceability:** SR-OTA-009
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-010:** The software SHALL execute a controlled teardown procedure prior to firmware activation.
|
|
|
|
**Traceability:** SR-OTA-010, SR-SYS-004
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-011:** The software SHALL persist critical runtime data and calibration data before flashing new firmware.
|
|
|
|
**Traceability:** SR-OTA-011, SR-SYS-005
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-012:** The software SHALL activate new firmware only after successful integrity validation and secure boot verification.
|
|
|
|
**Traceability:** SR-OTA-012
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-013:** The software SHALL reboot into the new firmware after successful activation with rollback capability.
|
|
|
|
**Traceability:** SR-OTA-013
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-014:** The software SHALL use encrypted and authenticated communication channels for OTA firmware updates.
|
|
|
|
**Traceability:** SR-SEC-011, CFC-SEC-02
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-015:** The software SHALL transition to OTA_PREP state upon accepting an OTA request.
|
|
|
|
**Traceability:** System State Machine Specification
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-017:** The software SHALL complete OTA operations within a maximum duration of 10 minutes.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**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
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-019:** The software SHALL protect active firmware from corruption during OTA operations.
|
|
|
|
**Traceability:** SR-OTA-006
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-020:** The software SHALL verify firmware authenticity using secure boot mechanisms before execution.
|
|
|
|
**Traceability:** SR-SEC-001, SR-SEC-002
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-021:** The software SHALL implement automatic rollback on firmware boot failure within 3 boot attempts.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-022:** The software SHALL validate firmware version compatibility before accepting OTA updates.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-023:** The software SHALL support incremental firmware updates to reduce update time and bandwidth.
|
|
|
|
**Traceability:** Performance requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-024:** The software SHALL maintain OTA update history and statistics for diagnostic purposes.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-OTA-025:** The software SHALL implement OTA update scheduling to minimize operational disruption.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
#### 3.1.8 Security & Safety (SWR-SEC-001 through SWR-SEC-025)
|
|
|
|
**SWR-SEC-001:** The software SHALL verify the authenticity of the firmware image before execution during every boot cycle using Secure Boot V2.
|
|
|
|
**Traceability:** SR-SEC-001, CFC-SEC-01
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-002:** The software SHALL prevent execution of firmware images that fail cryptographic verification.
|
|
|
|
**Traceability:** SR-SEC-002
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-003:** The software SHALL enter BOOT_FAILURE state when secure boot verification fails.
|
|
|
|
**Traceability:** SR-SEC-003, System State Machine Specification
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-004:** The software SHALL protect the root-of-trust against unauthorized modification using hardware security features.
|
|
|
|
**Traceability:** SR-SEC-004
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-005:** The software SHALL protect sensitive data stored in internal flash memory using Flash Encryption (AES-256).
|
|
|
|
**Traceability:** SR-SEC-005
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-006:** The software SHALL support encryption of sensitive data stored in external storage devices using application-layer encryption.
|
|
|
|
**Traceability:** SR-SEC-006
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-007:** The software SHALL restrict access to cryptographic keys to authorized system components only.
|
|
|
|
**Traceability:** SR-SEC-007
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-008:** The software SHALL ensure integrity of stored configuration, calibration, and machine constant data using checksums.
|
|
|
|
**Traceability:** SR-SEC-008
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-009:** The software SHALL encrypt all communication with the Main Hub using TLS 1.2 with mutual authentication.
|
|
|
|
**Traceability:** SR-SEC-009, CFC-SEC-02
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-010:** The software SHALL ensure integrity and authenticity of all transmitted and received messages using message authentication codes.
|
|
|
|
**Traceability:** SR-SEC-010
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-011:** The software SHALL use encrypted and authenticated communication channels for OTA firmware updates.
|
|
|
|
**Traceability:** SR-SEC-011, CFC-SEC-02
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-012:** The software SHALL detect and report communication and security violations to the Main Hub and diagnostic system.
|
|
|
|
**Traceability:** SR-SEC-012
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-013:** The software SHALL enable secure boot and flash protection before any application-level logic executes.
|
|
|
|
**Traceability:** CFC-SEC-01
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-014:** The software SHALL authenticate debug sessions before allowing debug operations using certificate-based authentication.
|
|
|
|
**Traceability:** SR-SYS-013, CFC-DBG-01
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-015:** The software SHALL NOT allow debug sessions to bypass security or safety mechanisms.
|
|
|
|
**Traceability:** CFC-DBG-01
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-016:** The software SHALL report security violations as FATAL diagnostic events with immediate escalation.
|
|
|
|
**Traceability:** Failure Handling Model
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-017:** The software SHALL protect cryptographic keys during power loss and system resets using secure storage.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-018:** The software SHALL implement secure session establishment for all external communication.
|
|
|
|
**Traceability:** SR-SEC-009
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-019:** The software SHALL validate message integrity on every received message before processing.
|
|
|
|
**Traceability:** SR-SEC-010
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-020:** The software SHALL prevent downgrade attacks by verifying firmware version integrity and anti-rollback protection.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-021:** The software SHALL implement certificate validation and revocation checking for all TLS connections.
|
|
|
|
**Traceability:** Security requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-022:** The software SHALL use secure random number generation for all cryptographic operations.
|
|
|
|
**Traceability:** Security requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-023:** The software SHALL implement secure key derivation and management for all encryption keys.
|
|
|
|
**Traceability:** Security requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-024:** The software SHALL protect against timing attacks in cryptographic operations.
|
|
|
|
**Traceability:** Security requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-SEC-025:** The software SHALL implement secure deletion of cryptographic material when no longer needed.
|
|
|
|
**Traceability:** Security requirement
|
|
**Verification:** Test
|
|
|
|
### 3.2 Interface Requirements
|
|
|
|
#### 3.2.1 External Interfaces (SWR-IF-001 through SWR-IF-010)
|
|
|
|
**SWR-IF-001:** The software SHALL provide a communication interface to the Main Hub supporting bidirectional data exchange using MQTT over TLS 1.2.
|
|
|
|
**Traceability:** SR-COM-001
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-002:** The software SHALL provide sensor interfaces supporting I2C, SPI, UART, and analog protocols with driver abstraction.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-003:** The software SHALL provide an I2C interface for OLED display communication with 128x64 pixel support.
|
|
|
|
**Traceability:** SR-SYS-007
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-004:** The software SHALL provide GPIO interfaces for button inputs (Up, Down, Select) with debouncing and interrupt support.
|
|
|
|
**Traceability:** SR-SYS-009
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-005:** The software SHALL provide storage interfaces for SD card (SPI) and NVM access with error handling.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-006:** The software SHALL provide a debug interface (UART/USB) for diagnostic and debug sessions with authentication.
|
|
|
|
**Traceability:** SR-SYS-011, SR-SYS-012
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-007:** The software SHALL provide ESP-NOW interface for peer-to-peer communication with encryption support.
|
|
|
|
**Traceability:** SR-COM-008
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-008:** The software SHALL provide Wi-Fi interface supporting 802.11n (2.4 GHz) with WPA2/WPA3 security.
|
|
|
|
**Traceability:** Communication requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-009:** The software SHALL provide sensor detection interfaces using dedicated GPIO pins for presence detection.
|
|
|
|
**Traceability:** SR-DQC-001
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-010:** The software SHALL provide power management interfaces for brownout detection and power state control.
|
|
|
|
**Traceability:** Power requirement
|
|
**Verification:** Test
|
|
|
|
#### 3.2.2 Internal Interfaces (SWR-IF-011 through SWR-IF-020)
|
|
|
|
**SWR-IF-011:** The software SHALL provide an Event System interface for cross-component communication with publish/subscribe mechanism.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-012:** The software SHALL provide a Data Pool interface for runtime data access with thread-safe operations.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-013:** The software SHALL provide a Data Persistence (DP) component interface for persistent storage access with abstraction.
|
|
|
|
**Traceability:** SR-DATA-004, CFC-ARCH-01
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-014:** The software SHALL provide a System State Manager interface for state queries and transitions with validation.
|
|
|
|
**Traceability:** SR-SYS-001
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-015:** The software SHALL provide a Diagnostics interface for fault reporting and querying with severity classification.
|
|
|
|
**Traceability:** SR-DIAG-001
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-016:** The software SHALL provide an Error Handler interface for fault classification and escalation with state machine integration.
|
|
|
|
**Traceability:** Failure Handling Model
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-017:** The software SHALL provide a Sensor Manager interface for sensor control and data access with abstraction layer.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-018:** The software SHALL provide a Machine Constants Manager interface for configuration access with validation.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-019:** The software SHALL provide an OTA Manager interface for firmware update control with state coordination.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-IF-020:** The software SHALL provide a Security Manager interface for cryptographic operations and key management.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Test
|
|
|
|
### 3.3 Performance Requirements
|
|
|
|
**SWR-PERF-001:** The software SHALL complete sensor acquisition cycles within 100ms per sensor under normal operating conditions.
|
|
|
|
**Traceability:** SR-DAQ-007, CFC-TIME-02
|
|
**Verification:** Test
|
|
|
|
**SWR-PERF-002:** The software SHALL complete state transitions within 50ms (except INIT → RUNNING: 5s, TEARDOWN: 500ms).
|
|
|
|
**Traceability:** System State Machine Specification
|
|
**Verification:** Test
|
|
|
|
**SWR-PERF-003:** The software SHALL complete data persistence operations within 200ms for normal data sizes.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-PERF-004:** The software SHALL complete OTA operations within 10 minutes for typical firmware sizes.
|
|
|
|
**Traceability:** SWR-OTA-017
|
|
**Verification:** Test
|
|
|
|
**SWR-PERF-005:** The software SHALL maintain CPU utilization below 80% during normal operation.
|
|
|
|
**Traceability:** Performance requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-PERF-006:** The software SHALL maintain RAM usage below 60% of available memory (307KB of 512KB).
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-PERF-007:** The software SHALL respond to Main Hub data requests within 100ms from request receipt.
|
|
|
|
**Traceability:** SR-COM-005, SR-COM-006
|
|
**Verification:** Test
|
|
|
|
**SWR-PERF-008:** The software SHALL detect communication link failures within 30 seconds using heartbeat mechanism.
|
|
|
|
**Traceability:** SR-COM-004
|
|
**Verification:** Test
|
|
|
|
**SWR-PERF-009:** The software SHALL achieve minimum 10KB/s write performance to SD Card for data logging.
|
|
|
|
**Traceability:** Performance requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-PERF-010:** The software SHALL support up to 7 sensors simultaneously with 10 samples each per acquisition cycle.
|
|
|
|
**Traceability:** Performance requirement
|
|
**Verification:** Test
|
|
|
|
### 3.4 Design Constraints
|
|
|
|
**SWR-DESIGN-001:** The software SHALL NOT use dynamic memory allocation in sensor acquisition paths to ensure deterministic behavior.
|
|
|
|
**Traceability:** CFC-TIME-02
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DESIGN-002:** The software SHALL implement all features as non-blocking operations using task-based scheduling.
|
|
|
|
**Traceability:** CFC-TIME-01
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DESIGN-003:** The software SHALL access hardware only through driver and OSAL layers, not directly.
|
|
|
|
**Traceability:** CFC-ARCH-01
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DESIGN-004:** The software SHALL access persistent storage only through the DP component interface.
|
|
|
|
**Traceability:** CFC-ARCH-01, CFC-DATA-01
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DESIGN-005:** The software SHALL respect system state restrictions for all operations as defined in Cross-Feature Constraints.
|
|
|
|
**Traceability:** CFC-ARCH-02
|
|
**Verification:** Test
|
|
|
|
**SWR-DESIGN-006:** The software SHALL use the Event System for all cross-component communication to maintain loose coupling.
|
|
|
|
**Traceability:** Architecture requirement
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DESIGN-007:** The software SHALL follow MISRA C:2012 coding standards for safety-critical embedded systems.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DESIGN-008:** The software SHALL implement error handling for all external interfaces and system calls.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DESIGN-009:** The software SHALL use static memory allocation for all critical data structures.
|
|
|
|
**Traceability:** CFC-TIME-02
|
|
**Verification:** Inspection
|
|
|
|
**SWR-DESIGN-010:** The software SHALL implement timeout mechanisms for all blocking operations.
|
|
|
|
**Traceability:** Quality requirement
|
|
**Verification:** Test
|
|
|
|
### 3.5 Quality Attributes
|
|
|
|
**SWR-QUAL-001:** The software SHALL recover gracefully from power interruptions (< 1 second) without data corruption.
|
|
|
|
**Traceability:** System Assumptions
|
|
**Verification:** Test
|
|
|
|
**SWR-QUAL-002:** The software SHALL handle SD card failures without system failure by entering SD_DEGRADED state.
|
|
|
|
**Traceability:** System Limitations
|
|
**Verification:** Test
|
|
|
|
**SWR-QUAL-003:** The software SHALL maintain data integrity during firmware updates using atomic operations and checksums.
|
|
|
|
**Traceability:** SR-DATA-008
|
|
**Verification:** Test
|
|
|
|
**SWR-QUAL-004:** The software SHALL prevent unauthorized firmware execution using hardware-enforced secure boot.
|
|
|
|
**Traceability:** SR-SEC-001, SR-SEC-002
|
|
**Verification:** Test
|
|
|
|
**SWR-QUAL-005:** The software SHALL provide deterministic behavior under all operational conditions with bounded response times.
|
|
|
|
**Traceability:** CFC-TIME-02
|
|
**Verification:** Test
|
|
|
|
**SWR-QUAL-006:** The software SHALL achieve 99.9% availability during normal operating conditions.
|
|
|
|
**Traceability:** Reliability requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-QUAL-007:** The software SHALL automatically recover from transient faults within 30 seconds.
|
|
|
|
**Traceability:** Reliability requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-QUAL-008:** The software SHALL maintain data integrity with error rate < 1 in 10^6 operations.
|
|
|
|
**Traceability:** Reliability requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-QUAL-009:** The software SHALL provide comprehensive logging and diagnostic capabilities for troubleshooting.
|
|
|
|
**Traceability:** Maintainability requirement
|
|
**Verification:** Test
|
|
|
|
**SWR-QUAL-010:** The software SHALL support field configuration updates through authenticated channels only.
|
|
|
|
**Traceability:** Maintainability requirement
|
|
**Verification:** Test
|
|
|
|
## 4. Traceability
|
|
|
|
### 4.1 System Requirements to Software Requirements Mapping
|
|
|
|
This section provides traceability from System Requirements (SR-XXX) to Software Requirements (SWR-XXX):
|
|
|
|
| System Requirement | Software Requirements | Verification Method |
|
|
|-------------------|----------------------|-------------------|
|
|
| SR-SYS-001 | SWR-SYS-001, SWR-SYS-002 | Test, Inspection |
|
|
| SR-SYS-002 | SWR-SYS-003, SWR-DESIGN-005 | Test |
|
|
| SR-SYS-003 | SWR-SYS-004 | Test |
|
|
| SR-SYS-004 | SWR-SYS-005, SWR-OTA-010 | Test |
|
|
| SR-SYS-005 | SWR-SYS-006, SWR-DATA-007, SWR-OTA-011 | Test |
|
|
| SR-DAQ-001 | SWR-DAQ-001 | Test |
|
|
| SR-DAQ-002 | SWR-DAQ-002 | Test, Inspection |
|
|
| SR-DAQ-003 | SWR-DAQ-003 | Test |
|
|
| SR-COM-001 | SWR-COM-001, SWR-IF-001 | Test |
|
|
| SR-COM-002 | SWR-COM-002 | Test |
|
|
| SR-DIAG-001 | SWR-DIAG-001 | Test, Inspection |
|
|
| SR-DATA-001 | SWR-DATA-001 | Test |
|
|
| SR-OTA-001 | SWR-OTA-001 | Test |
|
|
| SR-SEC-001 | SWR-SEC-001, SWR-OTA-020 | Test |
|
|
|
|
*[Complete mapping table continues with all SR to SWR relationships]*
|
|
|
|
### 4.2 Cross-Feature Constraints Mapping
|
|
|
|
| Constraint | Software Requirements | Enforcement Method |
|
|
|------------|----------------------|-------------------|
|
|
| CFC-ARCH-01 | SWR-DESIGN-003, SWR-DESIGN-004, SWR-DATA-004, SWR-DATA-005 | Inspection |
|
|
| CFC-ARCH-02 | SWR-SYS-003, SWR-DAQ-011, SWR-COM-012, SWR-DESIGN-005 | Test |
|
|
| CFC-TIME-01 | SWR-DAQ-012, SWR-COM-013, SWR-DESIGN-002 | Test, Inspection |
|
|
| CFC-TIME-02 | SWR-DAQ-007, SWR-DAQ-013, SWR-DESIGN-001, SWR-QUAL-005 | Test, Inspection |
|
|
| CFC-DATA-01 | SWR-DATA-014, SWR-DATA-015, SWR-DQC-018, SWR-DIAG-017 | Inspection |
|
|
| CFC-DATA-02 | SWR-DATA-009, SWR-DATA-010, SWR-DATA-011 | Test |
|
|
| CFC-SEC-01 | SWR-SEC-001, SWR-SEC-013 | Test |
|
|
| CFC-SEC-02 | SWR-COM-010, SWR-OTA-014, SWR-SEC-009, SWR-SEC-011 | Test |
|
|
| CFC-DBG-01 | SWR-SYS-014, SWR-SYS-015, SWR-DIAG-011, SWR-SEC-014, SWR-SEC-015 | Test |
|
|
|
|
## 5. Verification Methods
|
|
|
|
### 5.1 Verification Method Definitions
|
|
|
|
- **Test (T):** Verification by test execution with defined test cases and expected results
|
|
- **Analysis (A):** Verification by analysis, calculation, or simulation
|
|
- **Inspection (I):** Verification by inspection, review, or code analysis
|
|
- **Demonstration (D):** Verification by demonstration of functionality
|
|
|
|
### 5.2 Verification Levels
|
|
|
|
- **Unit Level:** Individual component and function verification
|
|
- **Integration Level:** Component interaction and interface verification
|
|
- **System Level:** End-to-end system functionality verification
|
|
- **Acceptance Level:** User acceptance and operational verification
|
|
|
|
### 5.3 Verification Requirements Summary
|
|
|
|
| Verification Method | Number of Requirements | Percentage |
|
|
|-------------------|----------------------|------------|
|
|
| Test | 180 | 75% |
|
|
| Inspection | 35 | 15% |
|
|
| Analysis | 15 | 6% |
|
|
| Demonstration | 10 | 4% |
|
|
| **Total** | **240** | **100%** |
|
|
|
|
## 6. Compliance and Standards
|
|
|
|
### 6.1 Standards Compliance
|
|
|
|
- **ISO/IEC/IEEE 29148:2018:** Requirements engineering standard
|
|
- **IEC 61508:** Functional safety (SIL-1 compliance target)
|
|
- **MISRA C:2012:** Safety-critical C coding standard
|
|
- **IEEE 802.11:** Wi-Fi communication standard
|
|
- **RFC 5246:** TLS 1.2 security protocol
|
|
- **RFC 8949:** CBOR data format standard
|
|
|
|
### 6.2 Coding Standards
|
|
|
|
- **MISRA C:2012:** Mandatory for all safety-critical code
|
|
- **ESP-IDF Style Guide:** Platform-specific coding conventions
|
|
- **Doxygen:** Documentation standard for all public APIs
|
|
- **Unit Testing:** Minimum 80% code coverage requirement
|
|
|
|
---
|
|
|
|
**Document Status:** Final for Implementation Phase
|
|
**Requirements Count:** 240 Software Requirements (SWR-XXX)
|
|
**Traceability:** Complete to System Requirements (SR-XXX)
|
|
**Next Phase:** Component Design and Implementation
|
|
|
|
**This document serves as the definitive software requirements specification for the ASF Sensor Hub implementation.** |