analysis
This commit is contained in:
359
System Design/system_arch_final/Features.md
Normal file
359
System Design/system_arch_final/Features.md
Normal file
@@ -0,0 +1,359 @@
|
||||
# **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
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user