Test Cases#

This page lists verification test cases for the score::time module, organized by functional requirement.

FR-1 Vehicle Time Synchronization#

TC-FR1-001 — gPTP Synchronization Establishment Verification#

Type:

System Function

Method:

Log + Packet Capture

Priority:

High

Preconditions

  1. Test device is powered on and started

  2. A gPTP Time Master is available in the network

  3. Wireshark/tcpdump is deployed on test PC or mirror port

  4. Device logs are accessible

Test Steps

  1. Start Wireshark on test PC, filter: eth.type == 0x88F7

  2. Start score::time service on target device

  3. Wait 60s

  4. Check captured gPTP packets in Wireshark

  5. Execute log view command on device

  6. Record AccuracyQualifier status in logs

Expected Result

Packet Capture

  • ✓ Pdelay_Req packets sent by this device are visible

  • ✓ Pdelay_Resp, Sync, Follow_Up packets received by this device are visible

  • ✓ No Sync packets sent by this device (device is Slave)

Log Verification

  • ✓ Log shows AccuracyQualifier changed to kSynchronized

  • ✓ No persistent ERROR-level logs

TC-FR1-002 — gPTP Master Disconnection State Degradation#

Type:

System Function

Method:

Log Verification

Priority:

High

Preconditions

  1. FR-1-001 completed, device is in kSynchronized state

  2. Device logs accessible

  3. Network connectivity of gPTP Master can be controlled (unplug cable or shut down Master service)

Test Steps

  1. Confirm AccuracyQualifier == kSynchronized in log, record timestamp

  2. Disconnect gPTP Master network

  3. Wait 60s (exceeds syncLossTimeout configuration)

  4. Check latest AccuracyQualifier status in device log

  5. Reconnect Master network

  6. Wait 60s

  7. Check AccuracyQualifier status in log again

Expected Result

Disconnection Phase

  • ✓ Log shows AccuracyQualifier degraded from kSynchronized to kUnstable or kNoTime

  • ✓ Sync loss warning/error present in log

Recovery Phase

  • ✓ Log shows kSynchronized state restored

  • ✓ No service crash during entire recovery process

TC-FR1-003 — Startup Behavior Without gPTP Master#

Type:

System Function

Method:

Log Verification

Priority:

High

Preconditions

  1. No gPTP Time Master in network (or Master is shut down)

  2. Device logs accessible

Test Steps

  1. Confirm no gPTP Master in network

  2. Restart score::time service on target device

  3. Wait 60s

  4. Check AccuracyQualifier status in log

  5. Verify service process is still running

Expected Result

Log Verification

  • ✓ AccuracyQualifier remains kNoTime

  • ✓ Log contains clear sync failure or waiting-for-Master records

Service Stability

  • ✓ Service process not crashed, running normally

  • ✓ No segfault or core dump

TC-FR1-004 — Device Does Not Send gPTP Sync Packets (Slave Role)#

Type:

System Function

Method:

Packet Capture

Priority:

Medium

Preconditions

  1. gPTP Time Master available in network

  2. Wireshark deployed

Test Steps

  1. Start Wireshark, filter: eth.type == 0x88F7

  2. Start score::time service, wait 120s

  3. Filter: source MAC is this device, gPTP messageType == Sync (0x0)

  4. Count number of such packets

Expected Result

Packet Capture

  • ✓ 0 Sync packets actively sent by this device

  • ✓ Pdelay_Req packets sent by this device visible (messageType == 0x2)

  • ✓ Sync and Follow_Up packets received by this device visible

FR-2 Vehicle Time Sync Precision#

TC-FR2-001 — AVB Node Synchronization Accuracy Verification (≤1 μs)#

Type:

Performance

Method:

Clock Comparison

Priority:

Medium

Preconditions

  1. Device is AVB node, gPTP sync completed

  2. Reference clock source (GPS or high-precision Master) available

  3. Accuracy measurement tool ready

Test Steps

  1. Wait for AccuracyQualifier == kSynchronized then wait 5 more minutes to stabilize

  2. Continuously sample for 10 minutes, record each offset

  3. Calculate: max offset, average offset, standard deviation

Expected Result

  • ✓ All sample offsets within 10 minutes have absolute value ≤ 1 μs

  • ✓ No abnormal jumps (single offset change ≤ 500 ns)

  • ✗ Fail if any sample offset > 1 μs

TC-FR2-002 — Non-AVB Node Synchronization Accuracy Verification (≤500 μs)#

Type:

Performance

Method:

Clock Comparison

Priority:

Medium

Preconditions

  1. Device is non-AVB node, gPTP sync completed

  2. Reference clock available

Test Steps

  1. Wait for sync to stabilize (AccuracyQualifier == kSynchronized, then wait 2 more minutes)

  2. Continuously sample for 5 minutes, record each offset

  3. Calculate max offset

Expected Result

  • ✓ All sample offsets have absolute value ≤ 500 μs

  • ✓ Most samples ≤ 200 μs (target range 200–500 μs)

  • ✗ Fail if offset > 500 μs

FR-3 Vehicle Time Base API#

TC-FR3-001 — Vehicle Time Now() Can Be Read Normally#

Type:

System Function

Method:

Test Tool

Priority:

High

Preconditions

  1. gPTP sync completed (AccuracyQualifier == kSynchronized)

  2. Test client tool deployed

Test Steps

  1. Call IVehicleTime::Now(), record return value T1

  2. Wait 1s

  3. Call Now() again, record T2

  4. Calculate T2 - T1

  5. Execute 10 consecutive times

Expected Result

  • ✓ Each call succeeds without error code

  • ✓ T2 > T1 (monotonically increasing)

  • ✓ T2 - T1 in range [950ms, 1050ms] (error ≤5%)

  • ✓ No crash or exception in all 10 calls

TC-FR3-002 — Vehicle Time Has Nanosecond Resolution#

Type:

System Function

Method:

Test Tool

Priority:

High

Preconditions

  1. gPTP sync completed

  2. Test client tool available

Test Steps

  1. Rapidly call Now() 10 consecutive times

  2. Record complete time value returned each time (including nanosecond portion)

  3. Check difference between adjacent return values

Expected Result

  • ✓ Return value contains non-zero nanosecond field

  • ✓ Difference between adjacent calls > 0 (time is advancing)

  • ✓ Difference value consistent with actual call interval, precision at microsecond level

TC-FR3-003 — Vehicle Time Aligned with gPTP Master Clock#

Type:

System Function

Method:

Test Tool + Clock Comparison

Priority:

High

Preconditions

  1. gPTP sync completed

  2. Current gPTP Master time is known

  3. Test tool available

Test Steps

  1. Read current time T_master from gPTP Master device

  2. Immediately read IVehicleTime::Now() from local device to get T_local

  3. Calculate abs(T_local - T_master)

  4. Repeat 5 times

Expected Result

  • ✓ abs(T_local - T_master) is within acceptable range (accounting for read operation latency)

  • ✓ 5 results are stable, no random jumps

FR-4 Vehicle Time Base Accuracy Qualifier#

TC-FR4-001 — AccuracyQualifier State: kNoTime#

Type:

System Function

Method:

Test Tool + Log Verification

Priority:

High

Preconditions

  1. No gPTP Master in network

  2. score::time service just started (first run, never synced)

  3. Test tool available

Test Steps

  1. Start score::time service in environment without Master

  2. Wait 10s

  3. Query GetAccuracyQualifier() return value

  4. Simultaneously check state record in log

Expected Result

  • ✓ GetAccuracyQualifier() returns kNoTime

  • ✓ Corresponding kNoTime state record present in log

  • ✓ Now() can still be called in this state (no crash)

TC-FR4-002 — AccuracyQualifier State: kSynchronized#

Type:

System Function

Method:

Test Tool + Log Verification

Priority:

High

Preconditions

  1. Stable gPTP Master available in network

  2. Test tool available

Test Steps

  1. Start score::time service, connect to gPTP Master

  2. After 60s query GetAccuracyQualifier()

  3. View log to confirm state transition (kNoTime → kUnstable → kSynchronized)

Expected Result

  • ✓ GetAccuracyQualifier() returns kSynchronized after 60s

  • ✓ State transition process visible in log

  • ✓ State transition order is reasonable

TC-FR4-003 — AccuracyQualifier State: kTimeJumpDetected#

Type:

System Function

Method:

Test Tool + Log Verification

Priority:

Medium

Preconditions

  1. Device is in kSynchronized state

  2. Large clock jump can be injected (> threshold)

Test Steps

  1. Confirm current state is kSynchronized

  2. Inject large time jump (local clock offset from Master > jump detection threshold, e.g., > 1ms)

  3. Immediately query GetAccuracyQualifier()

  4. Query again after 30s

Expected Result

  • ✓ GetAccuracyQualifier() returns kTimeJumpDetected after jump injection

  • ✓ Clock jump detection record present in log

  • ✓ System recovers from kTimeJumpDetected after 30s

TC-FR4-004 — AccuracyQualifier State: kUnstable#

Type:

System Function

Method:

Test Tool + Log Verification

Priority:

Medium

Preconditions

  1. gPTP Master signal quality can be degraded (e.g., via network emulator to introduce jitter)

  2. Test tool available

Test Steps

  1. Device is in kSynchronized state

  2. Introduce persistent high jitter or intermittent packet loss to gPTP network

  3. Wait 20s, query GetAccuracyQualifier()

  4. Restore network quality, wait 60s, query again

Expected Result

  • ✓ GetAccuracyQualifier() returns kUnstable during degradation period

  • ✓ Log contains accuracy instability records

  • ✓ State returns to kSynchronized after network recovery

FR-5 Vehicle Time Base Time Point Qualifier#

TC-FR5-001 — TimePointQualifier ASIL Safety Level Query#

Type:

System Function

Method:

Test Tool

Priority:

Medium

Preconditions

  1. score::time service running

  2. ASIL-B safety clock source configured

  3. Test tool available

Test Steps

  1. Query GetTimePointQualifier() when safety clock source is normal

  2. Simulate safety clock source failure (or degrade to QM source)

  3. Query GetTimePointQualifier() again

Expected Result

  • ✓ Returns kASIL_B when safety clock source is normal

  • ✓ Degrades to kQM after safety clock source failure

  • ✓ State changes are logged

FR-6 Vehicle Time Control Flow#

TC-FR6-001 — Now() Call Performance (Low Latency)#

Type:

Performance

Method:

Test Tool

Priority:

Medium

Preconditions

  1. score::time service running

  2. Test tool supports high-frequency calls and timing statistics

Test Steps

  1. Continuously call IVehicleTime::Now() 1000 times

  2. Record each call latency

  3. Calculate: average latency, P99 latency, max latency

Expected Result

  • ✓ Average call latency < 1 μs

  • ✓ P99 latency < 5 μs

  • ✓ No single call exceeds 100 μs (no kernel syscall blocking)

Note: If latency is significantly high (>10 μs average), shared memory mechanism may not be working

FR-7 Vehicle Time Synchronization Logging#

TC-FR7-001 — Sync State Change Log Recording#

Type:

Manual Acceptance

Method:

Log Verification

Priority:

High

Preconditions

  1. Device logs accessible

  2. Network environment controllable (can disconnect/restore gPTP Master)

Test Steps

  1. Clear or mark current log position

  2. Disconnect gPTP Master network, wait 30s

  3. Restore Master network, wait 60s

  4. View log, search keywords: AccuracyQualifier, sync, kSynchronized, kNoTime, kUnstable

Expected Result

  • ✓ Log contains AccuracyQualifier state change records (with timestamp)

  • ✓ Degradation log present when Master disconnects

  • ✓ Re-sync log present when Master restores

  • ✓ Log timestamp format is correct

TC-FR7-002 — Sync Statistics Log (Offset/Frequency)#

Type:

Manual Acceptance

Method:

Log Verification

Priority:

Medium

Preconditions

  1. Device in sync state, logs accessible

Test Steps

  1. Run for 10 minutes, view periodic sync statistics in log

  2. Search keywords: offset, rate, correction, pDelay

Expected Result

  • ✓ Log contains periodically recorded clock offset values

  • ✓ Rate correction (rateCorrection) or path delay (pDelay) logs present

  • ✓ Values within reasonable range, no abnormal values

TC-FR7-003 — Logging Does Not Block Sync Main Process#

Type:

Manual Acceptance

Method:

Log Verification + Clock Comparison

Priority:

Low

Preconditions

  1. Device in sync state

Test Steps

  1. Monitor both log output and sync accuracy (offset) simultaneously

  2. Measure sync accuracy during high-frequency log output (debug level)

  3. Disable verbose logging, measure accuracy again

  4. Compare accuracy difference between the two modes

Expected Result

  • ✓ Sync accuracy not significantly degraded with verbose logging enabled (offset increase < 50 μs)

  • ✓ Log thread does not affect real-time performance of sync main thread

FR-8 score::time External Synchronization#

TC-FR8-001 — NTP Sync Source Configuration and Connection#

Type:

System Function

Method:

Log Verification

Priority:

Medium

Preconditions

  1. NTP Server accessible in network

  2. score::time NTP function configuration enabled

  3. Logs accessible

Test Steps

  1. Configure NTP Server address

  2. Restart score::time service

  3. Wait 120s

  4. Check NTP sync status in log (search: NTP, AbsoluteTime, synchronized)

Expected Result

  • ✓ Log shows NTP sync success record

  • ✓ No persistent NTP connection failure errors in log

  • ✓ AbsoluteTime-related log has state update records

TC-FR8-002 — Fallback Behavior When NTP Server Unreachable#

Type:

System Function

Method:

Log Verification

Priority:

Medium

Preconditions

  1. NTP function enabled

  2. NTP Server address configured as unreachable

Test Steps

  1. Configure NTP Server to unreachable address (e.g., 192.0.2.1)

  2. Restart service, wait 120s

  3. Check AbsoluteTime AccuracyQualifier status in log

Expected Result

  • ✓ Log contains NTP connection failure record

  • ✓ IAbsoluteTime AccuracyQualifier does not enter synchronized state

  • ✓ Service does not crash, continues providing other functions

FR-9 Absolute Time Base API#

TC-FR9-001 — IAbsoluteTime::Now() Returns UTC Time#

Type:

System Function

Method:

Test Tool

Priority:

Medium

Preconditions

  1. NTP sync completed

  2. Test tool available

  3. Accurate UTC time known (confirmed via phone or other device)

Test Steps

  1. Call IAbsoluteTime::Now()

  2. Record returned UTC time

  3. Compare with UTC time displayed on reference device

Expected Result

  • ✓ Return value is valid UTC timestamp (UNIX Epoch format, not 0)

  • ✓ Offset from reference UTC time < 1s (NTP accuracy range)

  • ✓ Time value monotonically increasing across multiple calls

FR-10 Absolute Time Base Accuracy Qualifier#

TC-FR10-001 — Absolute Time AccuracyQualifier State Verification#

Type:

System Function

Method:

Test Tool + Log Verification

Priority:

Medium

Preconditions

  1. Test tool available

  2. NTP sync state controllable

Test Steps

  1. Query IAbsoluteTime GetAccuracyQualifier() when NTP not synced, record state

  2. Query again after NTP sync completed

  3. View log records of absolute time accuracy

Expected Result

  • ✓ Returns appropriate low accuracy level when NTP not synced

  • ✓ Accuracy level improves after NTP sync

  • ✓ Accuracy level changes are logged

FR-11 Absolute Time Base Security Qualifier#

TC-FR11-001 — Absolute Time SecurityQualifier State Verification#

Type:

System Function

Method:

Test Tool + Log Verification

Priority:

Medium

Preconditions

  1. Test tool available

  2. Different security level clock sources can be simulated

Test Steps

  1. Query IAbsoluteTime GetSecurityQualifier() when using unauthenticated NTP source

  2. Query again when using authenticated/secure NTP source

  3. View security level records in log

Expected Result

Security levels (low to high): NoTimeAvailable, NotTrustworthy, Trustworthy, VeryTrustworthy

  • ✓ Returns corresponding security level for different security sources

  • ✓ State changes are logged

FR-12 Absolute Time Synchronization Status Log#

TC-FR12-001 — Absolute Time Sync Log Recording#

Type:

Manual Acceptance

Method:

Log Verification

Priority:

Low

Preconditions

  1. NTP sync function enabled

  2. Logs accessible

Test Steps

  1. Perform NTP sync operation (restart service to re-sync)

  2. View log, search: AbsoluteTime, NTP, UTC

  3. Check log content completeness

Expected Result

  • ✓ Log contains NTP sync start/completion records

  • ✓ Absolute time accuracy level change records present

  • ✓ Security level status records present

  • ✓ Log format includes timestamp

FR-13 High Precision Clock API#

TC-FR13-001 — HighPrecisionClock::Now() Returns High Precision Time#

Type:

System Function

Method:

Test Tool

Priority:

Medium

Preconditions

  1. Test tool available

  2. System clock (CLOCK_REALTIME) synchronized

Test Steps

  1. Call HighPrecisionClockImpl::Now()

  2. Record returned time value (precise to nanoseconds)

  3. Compare with system clock_gettime(CLOCK_REALTIME) return value

  4. Call 10 consecutive times, confirm monotonicity

Expected Result

  • ✓ Return value differs from system CLOCK_REALTIME time by < 1ms

  • ✓ Return value has nanosecond precision

  • ✓ 10 consecutive calls are monotonically increasing

  • ✓ No call failures

TC-FR13-002 — Time Relationship Between HighPrecisionClock and VehicleTime#

Type:

System Function

Method:

Test Tool

Priority:

Low

Preconditions

  1. gPTP sync completed

  2. Test tool can read both interfaces simultaneously

Test Steps

  1. Simultaneously call HighPrecisionClockImpl::Now() and IVehicleTime::Now()

  2. Calculate difference between them

  3. Repeat 5 times

Expected Result

  • ✓ Difference is stable (fixed offset, not randomly varying)

  • ✓ Variance of difference < 100 μs (indicating both synced to same clock domain)

FR-14 Monotonic Clock API#

TC-FR14-001 — MonotonicClock::Now() Monotonicity Verification#

Type:

System Function

Method:

Test Tool

Priority:

High

Preconditions

  1. Test tool available

Test Steps

  1. Call MonotonicClockImpl::Now() 20 times at 100ms intervals

  2. Record each return value

  3. Check if sequence is strictly increasing

Expected Result

  • ✓ All 20 return values strictly increasing (T[i+1] > T[i])

  • ✓ Adjacent differences approximately 100ms (error < 5%)

  • ✓ No wraparound or jumps

TC-FR14-002 — MonotonicClock Maintains Monotonicity During System Clock Adjustment#

Type:

System Function

Method:

Test Tool

Priority:

High

Preconditions

  1. Test tool available

  2. Permission to adjust system clock (date -s or chronyc makestep)

Test Steps

  1. Start continuous sampling of MonotonicClock::Now() at 50ms intervals

  2. Execute system time jump during sampling (e.g., advance clock by 5s)

  3. Continue sampling for 30s

  4. Check monotonicity of complete sample sequence

Expected Result

  • ✓ Entire sample sequence (including during clock jump) is strictly monotonically increasing

  • ✓ MonotonicClock is not affected by system clock adjustment

TC-FR14-003 — MonotonicClock Corresponds to CLOCK_MONOTONIC#

Type:

System Function

Method:

Test Tool

Priority:

Medium

Preconditions

  1. Test tool available

  2. Can read system CLOCK_MONOTONIC at the same time

Test Steps

  1. Simultaneously call MonotonicClockImpl::Now() and system clock_gettime(CLOCK_MONOTONIC)

  2. Compare two return values

  3. Repeat 5 times

Expected Result

  • ✓ Two values approximately equal (difference < 1ms)

  • ✓ Both increase at the same rate

FR-15 score::time Mocking APIs#

TC-FR15-001 — ManualVehicleTime Can Set Time Manually#

Type:

System Function

Method:

Test Tool

Priority:

Medium

Preconditions

  1. score::time service started in Mock mode (ManualVehicleTime implementation)

  2. Test tool available

Test Steps

  1. Set ManualVehicleTime to specified time T_set (e.g., 2024-01-01 12:00:00)

  2. Call IVehicleTime::Now(), record T_read

  3. Wait 1s, call Now() again, record T_read2

Expected Result

  • ✓ T_read == T_set (allow < 1ms error)

  • ✓ T_read2 == T_set (time does not advance automatically unless manually advanced)

  • ✓ Does not depend on real gPTP network

TC-FR15-002 — ManualVehicleTime Time Can Be Manually Advanced#

Type:

System Function

Method:

Test Tool

Priority:

Medium

Preconditions

  1. Mock mode started, ManualVehicleTime initial time set

  2. Test tool available

Test Steps

  1. Record current ManualVehicleTime value T0

  2. Advance time by +500ms via test tool

  3. Call Now(), record T1

  4. Advance by +1s more

  5. Call Now(), record T2

Expected Result

  • ✓ T1 - T0 == 500ms (error < 1ms)

  • ✓ T2 - T1 == 1s (error < 1ms)

  • ✓ Time advancement is controllable, not affected by system clock

TC-FR15-003 — ManualVehicleTime AccuracyQualifier Can Be Set Manually#

Type:

System Function

Method:

Test Tool

Priority:

Medium

Preconditions

  1. Mock mode started

Test Steps

  1. Set AccuracyQualifier to kNoTime, confirm with GetAccuracyQualifier()

  2. Set to kSynchronized, confirm again

  3. Set to kUnstable, confirm again

Expected Result

  • ✓ All 3 settings take effect, GetAccuracyQualifier() return value matches set value

  • ✓ State switching causes no crash

TC-FR15-004 — ManualAbsoluteTime Can Set UTC Time#

Type:

System Function

Method:

Test Tool

Priority:

Low

Preconditions

  1. Mock mode started (ManualAbsoluteTime implementation)

  2. Test tool available

Test Steps

  1. Set ManualAbsoluteTime to specified UTC time

  2. Call IAbsoluteTime::Now(), verify return value

  3. Set SecurityQualifier to Trustworthy, verify GetSecurityQualifier() return value

Expected Result

  • ✓ IAbsoluteTime::Now() returns the set UTC time

  • ✓ GetSecurityQualifier() returns Trustworthy

  • ✓ Function decoupled from real NTP sync behavior

TC-FR15-005 — ManualMonotonicClock Isolation in Unit Tests#

Type:

Manual Acceptance

Method:

Test Tool

Priority:

Low

Preconditions

  1. Unit test framework configured to use Mock implementation

  2. No real hardware environment required

Test Steps

  1. Run unit tests using ManualMonotonicClock

  2. Manually set and advance time in tests, verify time-related logic

  3. Confirm tests do not depend on system time

Expected Result

  • ✓ Unit tests pass without gPTP/NTP network environment

  • ✓ Test execution time not affected by system clock

  • ✓ Mock object behavior consistent with interface specification

On this page
Edit on GitHub

This Page