7.2 KiB
Feature Engineering Specification
Diagnostics & Health Monitoring Features
Feature Group ID: FG-DIAG
Scope: Sensor Hub (Sub-Hub only)
Target Platform: ESP32-S3–based Sensor Hub
Applies To: Indoor poultry farm sensor hubs
Dependencies:
-
Sensor Data Acquisition (FG-DAQ)
-
Data Quality & Calibration (FG-DQC)
-
Communication Features (FG-COM)
-
Persistence / DP Stack
1. Purpose and Objectives
The Diagnostics & Health Monitoring Features provide a structured and persistent mechanism to detect, classify, record, and expose system faults, warnings, and health states.
These features ensure that:
-
Failures are detectable and explainable
-
Root causes are traceable
-
Diagnostic data survives resets and power loss
-
Engineers can access diagnostic information locally or remotely
The diagnostics subsystem is non-intrusive, meaning it shall not block core sensing or communication functions unless the system enters a fatal state.
2. Feature Overview and Relationships
Feature ID | Feature Name | Primary Objective | Related Features |
|---|---|---|---|
F-DIAG-01 | Diagnostic Code Management | Standardize fault and warning identification | DQC, COM |
F-DIAG-02 | Diagnostic Data Storage | Persist diagnostic events | DP Stack |
F-DIAG-03 | Diagnostic Session | Engineer access to diagnostics | COM, System Mgmt |
3. Functional Feature Descriptions
3.1 F-DIAG-01: Diagnostic Code Management
Description
The system shall implement a structured diagnostic code framework to represent system health conditions, warnings, errors, and fatal faults.
Each diagnostic event is associated with:
-
A unique diagnostic code
-
Severity level (info, warning, error, fatal)
-
A hierarchical root-cause classification
-
Timestamp and source component
This framework enables consistent fault handling across all system components.
Key Capabilities
-
Unique diagnostic code registry
-
Severity classification
-
Root-cause hierarchy
-
Event-based reporting
3.2 F-DIAG-02: Diagnostic Data Storage
Description
The system shall persist diagnostic events in non-volatile storage to allow post-failure analysis and long-term health monitoring.
Stored diagnostics remain available across system resets and power cycles until explicitly cleared by an authorized diagnostic session or command.
Key Capabilities
-
Persistent storage of diagnostic events
-
Timestamped records
-
Bounded storage with overwrite policy
-
Integration with DP / Persistence layer
3.3 F-DIAG-03: Diagnostic Session
Description
The system shall provide a diagnostic session that allows authorized engineers or tools to access diagnostic data, inspect system health, and perform maintenance operations.
The diagnostic session may be accessed locally or remotely via the communication interface and supports read and limited control operations.
Key Capabilities
-
Session-based access
-
Read diagnostics and health data
-
Clear diagnostic records
-
Controlled command execution
4. System Requirements (Formal SHALL Statements)
4.1 Diagnostic Code Management
SR-DIAG-001
The system shall implement a diagnostic code framework for reporting system health, warnings, errors, and fatal faults.
SR-DIAG-002
The system shall assign a unique diagnostic code to each detected fault or abnormal condition.
SR-DIAG-003
The system shall classify diagnostic codes by severity level.
SR-DIAG-004
The system shall associate each diagnostic event with a timestamp and source component.
4.2 Diagnostic Data Storage
SR-DIAG-005
The system shall persist diagnostic events in non-volatile storage.
SR-DIAG-006
The system shall retain diagnostic data across system resets and power cycles.
SR-DIAG-007
The system shall implement a bounded diagnostic storage mechanism with a defined overwrite or rollover policy.
4.3 Diagnostic Session
SR-DIAG-008
The system shall provide a diagnostic session interface for accessing diagnostic data.
SR-DIAG-009
The system shall allow authorized diagnostic sessions to retrieve stored diagnostic events.
SR-DIAG-010
The system shall allow authorized diagnostic sessions to clear diagnostic records.
SR-DIAG-011
The system shall ensure that diagnostic sessions do not interfere with normal sensor acquisition or communication operations.
5. Feature ↔ System Requirement Mapping
Feature ID | System Requirements |
|---|---|
F-DIAG-01 | SR-DIAG-001, SR-DIAG-002, SR-DIAG-003, SR-DIAG-004 |
F-DIAG-02 | SR-DIAG-005, SR-DIAG-006, SR-DIAG-007 |
F-DIAG-03 | SR-DIAG-008, SR-DIAG-009, SR-DIAG-010, SR-DIAG-011 |
6. Engineering Notes
-
Diagnostic codes should be versioned to support firmware evolution.
-
Diagnostic severity may be linked to LED indicators (green/yellow/red).
-
Fatal diagnostics may trigger the teardown mechanism defined elsewhere.
-
Security and access control for diagnostic sessions are handled under Security & Safety Features.