Add Basic DOM Functionality test codes

docs/testplan/transceiver/dom_test_plan.md

@@ -74,6 +74,12 @@ The following table summarizes the key attributes used in DOM testing. This tabl
 | rx_power_threshold_range | dict | (format) {"lowalarm": <float>, "lowwarning": <float>, "highwarning": <float>, "highalarm": <float>} | O | transceivers | Absolute threshold RX power range in dBm (omit attribute to skip RX power threshold validation) |
 | max_update_time_sec | integer | 60 | O | platform | Maximum expected time in seconds between DOM data updates for continuous monitoring validation |
 | consistency_check_poll_count | integer | 3 | O | transceivers or platform | Number of polling cycles to perform when validating DOM data consistency and variation patterns |
+| tx_power_consistency_variation_threshold | float | 3.0 | O | transceivers or platform | Maximum allowed Tx power variation between two consecutive TC4 polling reads |
+| rx_power_consistency_variation_threshold | float | 3.0 | O | transceivers or platform | Maximum allowed Rx power variation between two consecutive TC4 polling reads |
+| tx_bias_consistency_variation_threshold | float | 10.0 | O | transceivers or platform | Maximum allowed Tx bias variation percentage between two consecutive TC4 polling reads |
+| laser_temperature_consistency_variation_threshold | float | 3.0 | O | transceivers or platform | Maximum allowed laser temperature variation between two consecutive TC4 polling reads |
+| temperature_consistency_variation_threshold | float | 3.0 | O | transceivers or platform | Maximum allowed module temperature variation between two consecutive TC4 polling reads |
+| voltage_consistency_variation_threshold | float | 0.1 | O | transceivers or platform | Maximum allowed module voltage variation between two consecutive TC4 polling reads |
 | shutdown_tx_bias_threshold | float | 0 | O | transceivers | Maximum TX bias current in mA expected when interface is shutdown |
 | shutdown_tx_power_threshold | float | -30.0 | O | transceivers | Maximum TX power in dBm expected when interface is shutdown |
 | shutdown_rx_power_threshold | float | -30.0 | O | transceivers | Maximum RX power in dBm expected on remote side when interface is shutdown |
@@ -173,7 +179,7 @@ The following tests from the [Transceiver Onboarding Test Infrastructure and Fra
 | 1 | DOM data availability verification | 1. Access DOM data from `TRANSCEIVER_DOM_SENSOR` table in STATE_DB for each port.<br>2. Verify `last_update_time` is within `data_max_age_min` minutes of current time to ensure data freshness.<br>3. Dynamically determine expected DOM fields based on attributes present in `dom.json` using the [Dynamic Field Mapping Algorithm](#dynamic-field-mapping-algorithm).<br>4. Validate presence of all dynamically determined expected fields in STATE_DB.<br>5. Skip validation for fields whose corresponding attributes are absent from `dom.json`. | All DOM fields corresponding to configured attributes are present and accessible from STATE_DB. DOM data is successfully retrieved without errors for all attribute-driven fields. Lane-specific fields are automatically expanded for all available lanes (1 to N) based on the `LANE_NUM` placeholder. Field expectations are dynamically derived using the mapping algorithm. Data freshness is confirmed with recent `last_update_time` timestamp. |
 | 2 | DOM sensor operational range validation | 1. Retrieve DOM sensor data from STATE_DB.<br>2. Verify `last_update_time` is within `data_max_age_min` minutes of current time to ensure data freshness.<br>3. For each attribute ending with `_operational_range` present in `dom.json`, validate the corresponding field(s) in STATE_DB using the [Dynamic Field Mapping Algorithm](#dynamic-field-mapping-algorithm).<br>4. Check that sensor values fall within the configured operational range.<br>5. Fail the test case if any values fall outside their respective operational ranges.<br>6. Log detailed information about any out-of-range values including actual vs expected ranges.<br>7. Only validate fields derived from attributes present in `dom.json`. | All DOM sensor values fall within their respective operational ranges during normal operation (only for parameters with configured operational range attributes). Test case fails if any sensor values fall outside their configured operational ranges. Data freshness is confirmed before validation. Lane-specific validation automatically performed for all available lanes using the `LANE_NUM` placeholder expansion. Parameter validation is dynamically determined from attribute table. Detailed logging provided for any out-of-range conditions. |
 | 3 | DOM threshold validation | 1. Retrieve threshold data from `TRANSCEIVER_DOM_THRESHOLD` table in STATE_DB.<br>2. Dynamically determine expected threshold fields based on attributes ending with `_threshold_range` present in `dom.json` using the [Dynamic Field Mapping Algorithm](#dynamic-field-mapping-algorithm).<br>3. For each determined threshold field, validate threshold data completeness by checking for corresponding alarm and warning thresholds (highalarm, lowalarm, highwarning, lowwarning).<br>4. Compare configured threshold ranges via attributes with thresholds values from DB and validate logical hierarchy (lowalarm < lowwarning < highwarning < highalarm).<br>5. For parameters that have both operational and threshold range attributes, validate that operational ranges fall within warning thresholds (lowwarning < operational_min and operational_max < highwarning).<br>6. Only validate threshold fields derived from attributes present in `dom.json`. | All threshold values are present and follow logical hierarchy. EEPROM thresholds align with configured threshold ranges when present. Operational ranges are properly positioned within warning threshold boundaries to ensure appropriate alarm behavior. Threshold data integrity is maintained in STATE_DB. Threshold validation is performed at transceiver level (no lane-specific expansion). Threshold validation is dynamically determined from attribute table. |
-| 4 | DOM data consistency verification | 1. Read DOM data `consistency_check_poll_count` times with `max_update_time_sec` intervals between readings.<br>2. Verify data consistency between readings.<br>3. Check that `last_update_time` field is being updated correctly with each polling cycle.<br>4. Validate that sensor readings show expected behavior (e.g., temperature variations within reasonable limits). | DOM data shows consistent and reasonable variations between polling intervals over `consistency_check_poll_count` polling cycles. The `last_update_time` field is properly updated with each polling cycle. No erratic or impossible sensor value changes are observed during the monitoring period. Variation patterns indicate stable DOM monitoring system operation. |
+| 4 | DOM data consistency verification | 1. Read DOM data `consistency_check_poll_count` times with `max_update_time_sec` intervals between readings.<br>2. Verify data consistency between readings.<br>3. Check that `last_update_time` field is being updated correctly with each polling cycle.<br>4. Validate that sensor readings show expected behavior using configured consistency variation thresholds: `tx_power_consistency_variation_threshold`, `rx_power_consistency_variation_threshold`, `tx_bias_consistency_variation_threshold`, `laser_temperature_consistency_variation_threshold`, `temperature_consistency_variation_threshold`, and `voltage_consistency_variation_threshold`. For Tx bias, apply percentage-based variation against the previous sample. For all other mapped parameters, apply absolute variation thresholds. | DOM data shows consistent and reasonable variations between polling intervals over `consistency_check_poll_count` polling cycles. The `last_update_time` field is properly updated with each polling cycle. No erratic or impossible sensor value changes are observed during the monitoring period. Variation checks are driven by the configured consistency variation threshold attributes. |
 
 ### Advanced DOM Testing
 

tests/transceiver/dom/__init__.py

@@ -0,0 +1 @@
+# DOM test package