360 lines
8.0 KiB
Markdown
360 lines
8.0 KiB
Markdown
# **ASF Sensor Hub – Feature Definition Document**
|
||
|
||
*(Global, Feature-Based, Architecture-Neutral)*
|
||
|
||
This document defines the **system features** of the ASF Sensor Hub subsystem, organized by functional categories.
|
||
It is intended to be used as:
|
||
|
||
* A **feature baseline** in ALM
|
||
* Input to **system requirements derivation**
|
||
* Reference for **architecture and software design**
|
||
* Traceability anchor to IEC 61508 / IEC 61499 style decomposition later
|
||
|
||
> ⚠️ **Important Scope Note**
|
||
> This document covers **ONLY the Sensor Hub (Sub-Hub)** based on **ESP32-S3**.
|
||
> Main Hub, Cloud, Farm Control Logic are **explicitly out of scope**.
|
||
|
||
---
|
||
|
||
## **1. System Context Overview**
|
||
|
||
The ASF Sensor Hub is a **distributed sensing node** deployed inside a poultry house.
|
||
Its primary responsibilities are:
|
||
|
||
* Acquisition of multiple environmental sensors
|
||
* Local preprocessing and validation of sensor data
|
||
* Persistent storage of data and configuration
|
||
* Secure communication with a Main Hub
|
||
* Support for diagnostics, maintenance, and OTA updates
|
||
* Safe operation under fault conditions
|
||
|
||
The Sensor Hub operates as an **autonomous embedded system** with defined lifecycle states.
|
||
|
||
---
|
||
|
||
## **2. Feature Categorization Overview**
|
||
|
||
The system features are grouped into the following categories:
|
||
|
||
1. **Sensor Data Acquisition Features**
|
||
2. **Data Quality & Calibration Features**
|
||
3. **Communication Features**
|
||
4. **Diagnostics & Health Monitoring Features**
|
||
5. **Persistence & Data Management Features**
|
||
6. **Firmware Update (OTA) Features**
|
||
7. **Security & Safety Features**
|
||
8. **System Management Features**
|
||
|
||
Each feature is described at a **functional level** (WHAT the system does, not HOW).
|
||
|
||
---
|
||
|
||
## **3. Sensor Data Acquisition Features**
|
||
|
||
### **F-DAQ-01: Multi-Sensor Data Acquisition**
|
||
|
||
The system provides the capability to acquire data from multiple environmental sensors connected to the Sensor Hub hardware.
|
||
|
||
Supported sensor types include:
|
||
|
||
* Temperature
|
||
* Humidity
|
||
* Carbon Dioxide (CO₂)
|
||
* Ammonia (NH₃)
|
||
* Volatile Organic Compounds (VOC)
|
||
* Particulate Matter (PM)
|
||
* Light Intensity
|
||
|
||
---
|
||
|
||
### **F-DAQ-02: High-Frequency Sampling and Local Filtering**
|
||
|
||
The system provides local preprocessing of sensor data by:
|
||
|
||
* Sampling each sensor multiple times per acquisition cycle
|
||
* Applying a fast local filtering mechanism
|
||
* Producing a single validated value per sensor per cycle
|
||
|
||
Filtering algorithms are **pluggable and configurable**.
|
||
|
||
---
|
||
|
||
### **F-DAQ-03: Timestamped Sensor Data Generation**
|
||
|
||
The system provides timestamped sensor data using a synchronized local time source.
|
||
|
||
Each sensor record includes:
|
||
|
||
* Sensor identifier
|
||
* Measured value
|
||
* Timestamp
|
||
* Data validity status
|
||
|
||
---
|
||
|
||
## **4. Data Quality & Calibration Features**
|
||
|
||
### **F-DQC-01: Automatic Sensor Detection**
|
||
|
||
The system provides automatic detection of sensor presence based on dedicated hardware detection signals.
|
||
|
||
Key characteristics:
|
||
|
||
* Each sensor slot is type-specific
|
||
* Sensor presence is detected during initialization and runtime
|
||
* Only detected sensors are initialized and sampled
|
||
|
||
---
|
||
|
||
### **F-DQC-02: Sensor Type Enforcement**
|
||
|
||
The system enforces sensor-slot compatibility to prevent incorrect sensor usage.
|
||
|
||
Each physical slot:
|
||
|
||
* Accepts only one sensor type
|
||
* Is mapped to a predefined sensor class in software
|
||
|
||
---
|
||
|
||
### **F-DQC-03: Sensor Failure Detection**
|
||
|
||
The system provides detection of sensor failures, including:
|
||
|
||
* Communication errors
|
||
* Out-of-range values
|
||
* Non-responsive sensors
|
||
|
||
Detected failures are classified and reported.
|
||
|
||
---
|
||
|
||
### **F-DQC-04: Machine Constants & Calibration Management**
|
||
|
||
The system provides a Machine Constants (MC) mechanism responsible for:
|
||
|
||
* Defining installed sensor types
|
||
* Holding sensor calibration parameters
|
||
* Defining communication parameters
|
||
* Defining system identity parameters
|
||
|
||
MC data is persistent and reloadable.
|
||
|
||
---
|
||
|
||
## **5. Communication Features**
|
||
|
||
### **F-COM-01: Main Hub Communication**
|
||
|
||
The system provides bidirectional communication with a Main Hub to:
|
||
|
||
* Send sensor data
|
||
* Send diagnostics information
|
||
* Receive configuration updates
|
||
* Receive firmware updates
|
||
|
||
---
|
||
|
||
### **F-COM-02: On-Demand Data Broadcasting**
|
||
|
||
The system provides on-demand transmission of the most recent sensor dataset upon request from the Main Hub.
|
||
|
||
---
|
||
|
||
### **F-COM-03: Peer Sensor Hub Communication**
|
||
|
||
The system provides limited peer-to-peer communication between Sensor Hubs for:
|
||
|
||
* Connectivity checks
|
||
* Time synchronization support
|
||
* Basic status exchange
|
||
|
||
This feature is **on-demand and optional**.
|
||
|
||
---
|
||
|
||
## **6. Diagnostics & Health Monitoring Features**
|
||
|
||
### **F-DIAG-01: Diagnostic Code Management**
|
||
|
||
The system provides structured diagnostics with:
|
||
|
||
* Diagnostic codes
|
||
* Severity levels
|
||
* Root cause hierarchy
|
||
* Timestamping
|
||
|
||
---
|
||
|
||
### **F-DIAG-02: Diagnostic Data Storage**
|
||
|
||
The system provides persistent storage of diagnostic events for post-analysis.
|
||
|
||
---
|
||
|
||
### **F-DIAG-03: Diagnostic Session**
|
||
|
||
The system provides a diagnostic session allowing engineers to:
|
||
|
||
* Retrieve diagnostic data
|
||
* Inspect system health
|
||
* Clear diagnostic records
|
||
|
||
---
|
||
|
||
## **7. Persistence & Data Management Features**
|
||
|
||
### **F-DATA-01: Persistent Sensor Data Storage**
|
||
|
||
The system provides persistent storage of sensor data in non-volatile memory (SD Card).
|
||
|
||
---
|
||
|
||
### **F-DATA-02: Data Persistence Abstraction (DP Component)**
|
||
|
||
The system provides a Data Persistence (DP) component responsible for:
|
||
|
||
* Abstracting storage media (SD / NVM)
|
||
* Managing write/read operations
|
||
* Ensuring data integrity
|
||
|
||
---
|
||
|
||
### **F-DATA-03: Safe Data Handling During State Transitions**
|
||
|
||
The system ensures that all critical data is safely stored before:
|
||
|
||
* Firmware update
|
||
* Configuration update
|
||
* System teardown
|
||
* Reset or restart
|
||
|
||
---
|
||
|
||
## **8. Firmware Update (OTA) Features**
|
||
|
||
### **F-OTA-01: OTA Update Negotiation**
|
||
|
||
The system provides an OTA handshake mechanism with the Main Hub to:
|
||
|
||
* Acknowledge update availability
|
||
* Signal readiness for update
|
||
|
||
---
|
||
|
||
### **F-OTA-02: Firmware Reception and Storage**
|
||
|
||
The system provides secure reception of firmware images and temporary storage on SD Card.
|
||
|
||
---
|
||
|
||
### **F-OTA-03: Firmware Integrity Validation**
|
||
|
||
The system validates firmware integrity using checksum or CRC before activation.
|
||
|
||
---
|
||
|
||
### **F-OTA-04: Safe Firmware Activation**
|
||
|
||
The system provides controlled firmware flashing and rollback-safe activation.
|
||
|
||
---
|
||
|
||
## **9. Security & Safety Features**
|
||
|
||
### **F-SEC-01: Secure Boot**
|
||
|
||
The system provides secure boot functionality to ensure only authenticated firmware is executed.
|
||
|
||
---
|
||
|
||
### **F-SEC-02: Secure Flash Storage**
|
||
|
||
The system provides encrypted flash storage for sensitive assets.
|
||
|
||
---
|
||
|
||
### **F-SEC-03: Encrypted Communication**
|
||
|
||
The system provides encrypted communication channels for all external data exchange.
|
||
|
||
---
|
||
|
||
## **10. System Management Features**
|
||
|
||
### **F-SYS-01: System State Management**
|
||
|
||
The system provides explicit lifecycle states including:
|
||
|
||
* Initialization
|
||
* Normal Operation
|
||
* Degraded Operation
|
||
* Update Mode
|
||
* Fault Mode
|
||
* Teardown Mode
|
||
|
||
---
|
||
|
||
### **F-SYS-02: Controlled Teardown Mechanism**
|
||
|
||
The system provides a controlled teardown mechanism that:
|
||
|
||
* Stops sensor acquisition
|
||
* Flushes all critical data
|
||
* Ensures persistent storage consistency
|
||
* Prepares the system for update or shutdown
|
||
|
||
---
|
||
|
||
### **F-SYS-03: Status Indication**
|
||
|
||
The system provides visual status indicators:
|
||
|
||
* Green: Normal operation
|
||
* Yellow: Warning state
|
||
* Red: Fatal error state
|
||
|
||
---
|
||
|
||
### **F-SYS-04: Debug & Engineering Sessions**
|
||
|
||
The system provides engineering access sessions allowing:
|
||
|
||
* Log inspection
|
||
* MC file inspection and update
|
||
* Command execution
|
||
* Controlled debugging
|
||
|
||
---
|
||
|
||
## **11. Feature Relationship Overview (High-Level)**
|
||
|
||
```
|
||
Sensor Acquisition
|
||
↓
|
||
Data Quality & Calibration
|
||
↓
|
||
Data Persistence
|
||
↓
|
||
Communication
|
||
↓
|
||
Diagnostics & System Management
|
||
↓
|
||
OTA / Security / Safety
|
||
```
|
||
|
||
* **Machine Constants** affect:
|
||
|
||
* Sensor initialization
|
||
* Calibration
|
||
* Communication
|
||
* **Diagnostics** span all features
|
||
* **Teardown** is a cross-cutting mechanism triggered by:
|
||
|
||
* OTA
|
||
* MC update
|
||
* Fatal faults
|
||
|
||
---
|
||
|