ASF-Nabd/ASF_01_sys_sw_arch
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

system update

Browse Source
This commit is contained in:
mahmamdouh
2026-02-01 12:52:10 +01:00
parent ff791564e4
commit f51adeecca
31 changed files with 7984 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

231
0 system_design/SRS/VV_Matrix.md Normal file
View File

@@ -0,0 +1,231 @@
# Verification & Validation Matrix
**Document:** SRS V&V Matrix
**Version:** 1.0
**Date:** 2025-01-19
## Purpose
This document maps Software Requirements (SWR-*) to verification methods (unit tests, integration tests, HIL tests) and defines acceptance criteria for each requirement.
## Verification Methods
| Method | Description | Scope |
|--------|-------------|-------|
| **UT** | Unit Test | Single component, isolated |
| **IT** | Integration Test | Multiple components, interactions |
| **HIL** | Hardware-In-the-Loop Test | Full system, real hardware |
| **REV** | Review | Design/code review, static analysis |
| **ANAL** | Analysis | Timing analysis, resource analysis |
## Acceptance Criteria Format
- **Pass:** Requirement satisfied
- **Fail:** Requirement not satisfied
- **N/A:** Not applicable for this verification method
## V&V Matrix
### System Management Requirements
| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
|--------|-------------|----|----|-----|-----|------|---------------------|
| SWR-SYS-001 | FSM Implementation | ✓ | ✓ | ✓ | ✓ | - | All 11 states implemented, transitions validated |
| SWR-SYS-002 | State Transition Enforcement | ✓ | ✓ | ✓ | ✓ | - | Invalid transitions rejected, valid transitions succeed |
| SWR-SYS-003 | State-Based Operation Restriction | ✓ | ✓ | ✓ | ✓ | - | Operations blocked in invalid states |
| SWR-SYS-004 | State Transition Notification | ✓ | ✓ | ✓ | - | - | All listeners notified within 50ms |
| SWR-SYS-005 | Controlled Teardown Execution | ✓ | ✓ | ✓ | ✓ | - | Teardown completes within 500ms |
| SWR-SYS-006 | Critical Data Persistence Before Teardown | ✓ | ✓ | ✓ | ✓ | - | All critical data flushed before teardown complete |
| SWR-SYS-007 | Data Integrity Protection During Shutdown | ✓ | ✓ | ✓ | ✓ | - | No data corruption during teardown/reset |
| SWR-SYS-008 | OLED Display Interface | ✓ | ✓ | ✓ | ✓ | - | OLED displays correctly via I2C |
| SWR-SYS-009 | System Information Display | ✓ | ✓ | ✓ | - | - | All required information displayed |
| SWR-SYS-010 | Button-Based Menu Navigation | ✓ | ✓ | ✓ | - | - | Menu navigation works correctly |
| SWR-SYS-011 | Local Diagnostic and Health Menus | ✓ | ✓ | ✓ | - | - | Diagnostic/health info accessible via menu |
| SWR-SYS-012 | Diagnostic Session Support | ✓ | ✓ | ✓ | ✓ | - | Diagnostic sessions functional |
| SWR-SYS-013 | Debug Session Support | ✓ | ✓ | ✓ | ✓ | - | Debug sessions functional |
| SWR-SYS-014 | Authorized Debug Access Control | ✓ | ✓ | ✓ | ✓ | - | Unauthorized access rejected |
| SWR-SYS-015 | Non-Intrusive Debug Sessions | ✓ | ✓ | ✓ | - | - | Debug sessions don't interfere with normal operation |
### Data Acquisition Requirements
| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
|--------|-------------|----|----|-----|-----|------|---------------------|
| SWR-DAQ-001 | Multi-Sensor Environmental Data Acquisition | ✓ | ✓ | ✓ | ✓ | - | All sensor types supported |
| SWR-DAQ-002 | Dedicated Sensor Slot Mapping | ✓ | ✓ | ✓ | ✓ | - | Each sensor type mapped to unique slot |
| SWR-DAQ-003 | Sensor Presence Detection | ✓ | ✓ | ✓ | - | - | Presence detection works correctly |
| SWR-DAQ-004 | Conditional Sensor Initialization | ✓ | ✓ | ✓ | - | - | Only present sensors initialized |
| SWR-DAQ-005 | High-Frequency Sensor Sampling | ✓ | ✓ | ✓ | ✓ | ✓ | 10 samples per cycle (default) |
| SWR-DAQ-006 | Local Sensor Data Filtering | ✓ | ✓ | ✓ | ✓ | - | Filtering produces single value |
| SWR-DAQ-007 | Deterministic Sampling Window | ✓ | ✓ | ✓ | ✓ | ✓ | Sampling completes within 100ms per sensor |
| SWR-DAQ-008 | Timestamp Generation for Sensor Data | ✓ | ✓ | ✓ | - | - | Timestamps generated correctly |
| SWR-DAQ-009 | Timestamped Sensor Data Record Structure | ✓ | ✓ | ✓ | ✓ | - | Record contains all required fields |
| SWR-DAQ-010 | Availability of Latest Sensor Data | ✓ | ✓ | ✓ | - | - | Latest data available in memory |
| SWR-DAQ-011 | State-Restricted Sensor Acquisition | ✓ | ✓ | ✓ | - | - | Acquisition blocked in OTA_UPDATE, MC_UPDATE, TEARDOWN |
| SWR-DAQ-012 | Non-Blocking Sensor Acquisition | ✓ | ✓ | ✓ | ✓ | ✓ | No blocking operations in acquisition path |
| SWR-DAQ-013 | Deterministic Memory Allocation | ✓ | ✓ | ✓ | ✓ | ✓ | No dynamic allocation in acquisition path |
| SWR-DAQ-014 | Sensor Data Event Publishing | ✓ | ✓ | ✓ | - | - | Events published via Event System |
| SWR-DAQ-015 | Failed Sensor Exclusion | ✓ | ✓ | ✓ | - | - | Failed sensors excluded from acquisition |
### Data Quality & Calibration Requirements
| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
|--------|-------------|----|----|-----|-----|------|---------------------|
| SWR-DQC-001 | Detect Sensor Presence | ✓ | ✓ | ✓ | - | - | Presence detection works correctly |
| SWR-DQC-002 | Perform Sensor Detection During Initialization | ✓ | ✓ | ✓ | - | - | Detection performed during init |
| SWR-DQC-003 | Conditional Sensor Initialization | ✓ | ✓ | ✓ | - | - | Only present sensors initialized |
| SWR-DQC-004 | Assign Fixed Sensor Slot Types | ✓ | ✓ | ✓ | ✓ | - | Each slot assigned to sensor type |
| SWR-DQC-005 | Verify Sensor Type Compatibility | ✓ | ✓ | ✓ | - | - | Sensor-slot compatibility verified |
| SWR-DQC-006 | Reject Invalid Sensor Configurations | ✓ | ✓ | ✓ | - | - | Invalid configurations rejected and reported |
| SWR-DQC-007 | Monitor Sensor Health | ✓ | ✓ | ✓ | - | - | Sensor health monitored continuously |
| SWR-DQC-008 | Detect Sensor Failure Conditions | ✓ | ✓ | ✓ | - | - | All failure conditions detected |
| SWR-DQC-009 | Isolate Failed Sensors | ✓ | ✓ | ✓ | - | - | Failed sensors marked and excluded |
| SWR-DQC-010 | Report Sensor Failures | ✓ | ✓ | ✓ | - | - | Failures reported to Main Hub |
| SWR-DQC-011 | Maintain Machine Constants Dataset | ✓ | ✓ | ✓ | ✓ | - | MC dataset maintained correctly |
| SWR-DQC-012 | Persist Machine Constants | ✓ | ✓ | ✓ | - | - | MC persisted to non-volatile storage |
| SWR-DQC-013 | Load Machine Constants at Startup | ✓ | ✓ | ✓ | - | - | MC loaded during initialization |
| SWR-DQC-014 | Support Remote Machine Constants Update | ✓ | ✓ | ✓ | - | - | Remote MC updates supported |
| SWR-DQC-015 | Controlled Reinitialization After Update | ✓ | ✓ | ✓ | - | - | Reinitialization after MC update |
| SWR-DQC-016 | Machine Constants Integrity Validation | ✓ | ✓ | ✓ | ✓ | - | MC integrity validated before apply |
| SWR-DQC-017 | State-Restricted Calibration | ✓ | ✓ | ✓ | - | - | Calibration blocked in OTA_UPDATE, MC_UPDATE, TEARDOWN |
| SWR-DQC-018 | Machine Constants Access via DP | ✓ | ✓ | ✓ | ✓ | - | MC accessed only via DP component |
### Communication Requirements
| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
|--------|-------------|----|----|-----|-----|------|---------------------|
| SWR-COM-001 | Bidirectional Main Hub Communication | ✓ | ✓ | ✓ | ✓ | - | Bidirectional communication functional |
| SWR-COM-002 | Transmit Data to Main Hub | ✓ | ✓ | ✓ | - | - | Sensor data, diagnostics, status transmitted |
| SWR-COM-003 | Receive Commands from Main Hub | ✓ | ✓ | ✓ | - | - | Commands, config updates, OTA requests received |
| SWR-COM-004 | Monitor Communication Link Status | ✓ | ✓ | ✓ | - | - | Link status monitored and reported |
| SWR-COM-005 | Support On-Demand Data Requests | ✓ | ✓ | ✓ | - | - | On-demand requests supported |
| SWR-COM-006 | Respond with Latest Sensor Data | ✓ | ✓ | ✓ | ✓ | ✓ | Response within 100ms with latest data |
| SWR-COM-007 | Include Data Validity in Responses | ✓ | ✓ | ✓ | - | - | Validity status included in responses |
| SWR-COM-008 | Support Peer Sensor Hub Communication | ✓ | ✓ | ✓ | - | - | Peer communication supported |
| SWR-COM-009 | Isolate Peer Communication | ✓ | ✓ | ✓ | - | - | Peer communication doesn't interfere |
| SWR-COM-010 | Encrypted Main Hub Communication | ✓ | ✓ | ✓ | ✓ | - | All communication encrypted |
| SWR-COM-011 | Message Integrity and Authenticity | ✓ | ✓ | ✓ | ✓ | - | Message integrity and authenticity verified |
| SWR-COM-012 | State-Restricted Communication | ✓ | ✓ | ✓ | - | - | Communication limited during TEARDOWN |
| SWR-COM-013 | Non-Blocking Communication | ✓ | ✓ | ✓ | ✓ | ✓ | Communication operations non-blocking |
| SWR-COM-014 | Communication Link Failure Reporting | ✓ | ✓ | ✓ | - | - | Link failures reported as diagnostics |
| SWR-COM-015 | Security Violation Reporting | ✓ | ✓ | ✓ | - | - | Security violations reported to Main Hub |
### Diagnostics Requirements
| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
|--------|-------------|----|----|-----|-----|------|---------------------|
| SWR-DIAG-001 | Diagnostic Code Framework | ✓ | ✓ | ✓ | ✓ | - | Diagnostic framework implemented |
| SWR-DIAG-002 | Assign Unique Diagnostic Codes | ✓ | ✓ | ✓ | ✓ | - | Each fault has unique code |
| SWR-DIAG-003 | Classify Diagnostic Severity | ✓ | ✓ | ✓ | ✓ | - | Severity classification correct |
| SWR-DIAG-004 | Timestamp and Source Diagnostics | ✓ | ✓ | ✓ | - | - | Timestamp and source associated |
| SWR-DIAG-005 | Persist Diagnostic Events | ✓ | ✓ | ✓ | - | - | Diagnostic events persisted |
| SWR-DIAG-006 | Retain Diagnostics Across Resets | ✓ | ✓ | ✓ | - | - | Diagnostics retained after reset |
| SWR-DIAG-007 | Bounded Diagnostic Storage | ✓ | ✓ | ✓ | ✓ | - | Storage bounded with overwrite policy |
| SWR-DIAG-008 | Provide Diagnostic Session Interface | ✓ | ✓ | ✓ | ✓ | - | Diagnostic session interface provided |
| SWR-DIAG-009 | Retrieve Diagnostic Records | ✓ | ✓ | ✓ | - | - | Diagnostic records retrievable |
| SWR-DIAG-010 | Clear Diagnostic Records | ✓ | ✓ | ✓ | - | - | Diagnostic records clearable |
| SWR-DIAG-011 | Non-Intrusive Diagnostic Sessions | ✓ | ✓ | ✓ | - | - | Sessions don't interfere with operation |
| SWR-DIAG-012 | Fault-to-State Transition | ✓ | ✓ | ✓ | - | - | Faults trigger state transitions |
| SWR-DIAG-013 | Fault Latching Behavior | ✓ | ✓ | ✓ | - | - | Fault latching works correctly |
| SWR-DIAG-014 | Fault Escalation Rules | ✓ | ✓ | ✓ | - | - | Escalation rules implemented |
| SWR-DIAG-015 | Diagnostic Event Reporting to Main Hub | ✓ | ✓ | ✓ | - | - | WARNING/ERROR/FATAL events reported |
| SWR-DIAG-016 | Diagnostic Information via HMI | ✓ | ✓ | ✓ | - | - | Diagnostic info accessible via HMI |
| SWR-DIAG-017 | Diagnostic Storage Access via DP | ✓ | ✓ | ✓ | ✓ | - | Diagnostics accessed only via DP |
| SWR-DIAG-018 | State-Restricted Diagnostic Generation | ✓ | ✓ | ✓ | - | - | Diagnostics limited during TEARDOWN |
### Persistence Requirements
| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
|--------|-------------|----|----|-----|-----|------|---------------------|
| SWR-DATA-001 | Persistent Timestamped Sensor Data | ✓ | ✓ | ✓ | - | - | Sensor data persisted correctly |
| SWR-DATA-002 | Sensor Data Metadata Storage | ✓ | ✓ | ✓ | ✓ | - | Metadata stored with sensor data |
| SWR-DATA-003 | Configurable Data Retention Policy | ✓ | ✓ | ✓ | ✓ | - | Retention policy configurable |
| SWR-DATA-004 | Data Persistence Component Interface | ✓ | ✓ | ✓ | ✓ | - | DP component is sole interface |
| SWR-DATA-005 | Storage Access Isolation | ✓ | ✓ | ✓ | ✓ | - | No direct storage access from application |
| SWR-DATA-006 | Structured Data Serialization | ✓ | ✓ | ✓ | ✓ | - | Serialization/deserialization works |
| SWR-DATA-007 | Data Flush Before Teardown | ✓ | ✓ | ✓ | ✓ | - | Critical data flushed before teardown |
| SWR-DATA-008 | Data Integrity During Updates | ✓ | ✓ | ✓ | ✓ | - | Data integrity maintained during updates |
| SWR-DATA-009 | Persistence Verification | ✓ | ✓ | ✓ | ✓ | - | Persistence verified before state transitions |
| SWR-DATA-010 | State-Restricted Data Writes | ✓ | ✓ | ✓ | - | - | Writes restricted during TEARDOWN |
| SWR-DATA-011 | Persistence Completion Confirmation | ✓ | ✓ | ✓ | - | - | Completion confirmed before transitions |
| SWR-DATA-012 | SD Card Failure Handling | ✓ | ✓ | ✓ | - | - | SD failures handled gracefully |
| SWR-DATA-013 | Wear-Aware Storage Management | ✓ | ✓ | ✓ | ✓ | - | Wear-aware management implemented |
| SWR-DATA-014 | Single Source of Truth | ✓ | ✓ | ✓ | ✓ | - | Single source of truth maintained |
| SWR-DATA-015 | No Private Persistent Copies | ✓ | ✓ | ✓ | ✓ | - | No private persistent copies |
### OTA Requirements
| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
|--------|-------------|----|----|-----|-----|------|---------------------|
| SWR-OTA-001 | OTA Negotiation Support | ✓ | ✓ | ✓ | - | - | OTA negotiation supported |
| SWR-OTA-002 | OTA Readiness Validation | ✓ | ✓ | ✓ | - | - | Readiness validated before acceptance |
| SWR-OTA-003 | OTA Acknowledgement | ✓ | ✓ | ✓ | - | - | OTA requests acknowledged/rejected |
| SWR-OTA-004 | Firmware Reception | ✓ | ✓ | ✓ | - | - | Firmware received over communication |
| SWR-OTA-005 | Firmware Temporary Storage | ✓ | ✓ | ✓ | - | - | Firmware stored in non-volatile storage |
| SWR-OTA-006 | Active Firmware Protection | ✓ | ✓ | ✓ | ✓ | - | Active firmware not overwritten |
| SWR-OTA-007 | Firmware Integrity Verification | ✓ | ✓ | ✓ | ✓ | - | Firmware integrity validated |
| SWR-OTA-008 | Firmware Rejection Handling | ✓ | ✓ | ✓ | - | - | Invalid firmware rejected |
| SWR-OTA-009 | OTA Status Reporting | ✓ | ✓ | ✓ | - | - | OTA status reported to Main Hub |
| SWR-OTA-010 | OTA Teardown Execution | ✓ | ✓ | ✓ | - | - | Teardown executed before activation |
| SWR-OTA-011 | Data Persistence Before Flashing | ✓ | ✓ | ✓ | - | - | Critical data persisted before flashing |
| SWR-OTA-012 | Controlled Firmware Activation | ✓ | ✓ | ✓ | ✓ | - | Firmware activated only after validation |
| SWR-OTA-013 | OTA Reboot Execution | ✓ | ✓ | ✓ | - | - | System reboots into new firmware |
| SWR-OTA-014 | Encrypted OTA Communication | ✓ | ✓ | ✓ | ✓ | - | OTA communication encrypted |
| SWR-OTA-015 | OTA State Transition | ✓ | ✓ | ✓ | - | - | Transitions to OTA_PREP on request |
| SWR-OTA-016 | State-Restricted OTA Operations | ✓ | ✓ | ✓ | - | - | OTA blocked in WARNING/FAULT/SERVICE/SD_DEGRADED |
| SWR-OTA-017 | OTA Duration Limit | ✓ | ✓ | ✓ | ✓ | ✓ | OTA completes within 10 minutes |
| SWR-OTA-018 | OTA Failure Handling | ✓ | ✓ | ✓ | - | - | OTA failures trigger FAULT state |
| SWR-OTA-019 | Active Firmware Corruption Protection | ✓ | ✓ | ✓ | ✓ | - | Active firmware protected during OTA |
| SWR-OTA-020 | Firmware Authenticity Verification | ✓ | ✓ | ✓ | ✓ | - | Firmware authenticity verified |
### Security Requirements
| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
|--------|-------------|----|----|-----|-----|------|---------------------|
| SWR-SEC-001 | Firmware Authenticity Verification | ✓ | ✓ | ✓ | ✓ | - | Firmware verified on every boot |
| SWR-SEC-002 | Unauthorized Firmware Blocking | ✓ | ✓ | ✓ | ✓ | - | Unauthorized firmware blocked |
| SWR-SEC-003 | Secure Boot Failure Handling | ✓ | ✓ | ✓ | - | - | BOOT_FAILURE state on secure boot failure |
| SWR-SEC-004 | Root-of-Trust Protection | ✓ | ✓ | ✓ | ✓ | - | Root-of-trust protected |
| SWR-SEC-005 | Flash Data Access Protection | ✓ | ✓ | ✓ | ✓ | - | Flash data access protected |
| SWR-SEC-006 | Encrypted External Storage | ✓ | ✓ | ✓ | ✓ | - | External storage encrypted |
| SWR-SEC-007 | Cryptographic Key Isolation | ✓ | ✓ | ✓ | ✓ | - | Keys isolated to authorized components |
| SWR-SEC-008 | Stored Data Integrity Assurance | ✓ | ✓ | ✓ | ✓ | - | Stored data integrity ensured |
| SWR-SEC-009 | Encrypted Main Hub Communication | ✓ | ✓ | ✓ | ✓ | - | All communication encrypted |
| SWR-SEC-010 | Message Integrity and Authenticity | ✓ | ✓ | ✓ | ✓ | - | Message integrity and authenticity verified |
| SWR-SEC-011 | Secure OTA Data Transfer | ✓ | ✓ | ✓ | ✓ | - | OTA data transfer encrypted |
| SWR-SEC-012 | Security Violation Reporting | ✓ | ✓ | ✓ | - | - | Security violations reported |
| SWR-SEC-013 | Security First Initialization | ✓ | ✓ | ✓ | ✓ | - | Secure boot enabled before application |
| SWR-SEC-014 | Debug Session Authentication | ✓ | ✓ | ✓ | ✓ | - | Debug sessions authenticated |
| SWR-SEC-015 | Debug Security Bypass Prevention | ✓ | ✓ | ✓ | ✓ | - | Debug cannot bypass security |
| SWR-SEC-016 | Security Violation Diagnostic Reporting | ✓ | ✓ | ✓ | - | - | Security violations reported as FATAL |
| SWR-SEC-017 | Cryptographic Key Protection | ✓ | ✓ | ✓ | ✓ | - | Keys protected during power loss |
| SWR-SEC-018 | Secure Session Establishment | ✓ | ✓ | ✓ | ✓ | - | Secure sessions established |
| SWR-SEC-019 | Message Integrity Validation | ✓ | ✓ | ✓ | ✓ | - | Message integrity validated on receive |
| SWR-SEC-020 | Downgrade Attack Prevention | ✓ | ✓ | ✓ | ✓ | - | Downgrade attacks prevented |
### Performance Requirements
| SWR ID | Requirement | UT | IT | HIL | REV | ANAL | Acceptance Criteria |
|--------|-------------|----|----|-----|-----|------|---------------------|
| SWR-PERF-001 | Sensor Acquisition Cycle Timing | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 100ms per sensor |
| SWR-PERF-002 | State Transition Timing | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 50ms (except INIT, TEARDOWN) |
| SWR-PERF-003 | Data Persistence Timing | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 200ms |
| SWR-PERF-004 | OTA Operation Duration | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 10 minutes |
| SWR-PERF-005 | CPU Utilization Limit | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 80% during normal operation |
| SWR-PERF-006 | RAM Usage Limit | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 60% of available memory |
| SWR-PERF-007 | Main Hub Response Time | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 100ms |
| SWR-PERF-008 | Communication Link Failure Detection | ✓ | ✓ | ✓ | ✓ | ✓ | ≤ 30 seconds |
## Test Coverage Summary
- **Total SWRs:** 200+
- **Unit Test Coverage:** ~180 SWRs (90%)
- **Integration Test Coverage:** ~190 SWRs (95%)
- **HIL Test Coverage:** ~150 SWRs (75%)
- **Review Coverage:** ~100 SWRs (50%)
- **Analysis Coverage:** ~30 SWRs (15%)
## Traceability
- **SRS Section 3:** All functional requirements covered
- **Annex C:** Timing and resource budgets verified
- **Component Specifications:** Component-level tests defined