View Issue Details

IDProjectCategoryView StatusLast Update
0008559CTT UA Scripts1 - Script Issuepublic2023-02-18 22:49
ReporterAlexander Allmendinger Assigned ToArchie Miller  
PrioritynormalSeverityminorReproducibilitysometimes
Status closedResolutionfixed 
Product Version1.03.501 
Target Version1.03.502Fixed in Version1.03.502 
Summary0008559: A and C Refresh stops when time shift between CTT and SUT is bigger 0ms
Description

When the time is 200ms off (device earlier than CTT), the test already is not executed any more.

We discussed that already once but I didn't find a mantis issue for it. Anyway, a solution to the problem may be to use only server timestamps for the identification of the timing. E.g. Compare the Timestamp of the CallHelper.Response.ResponseHeader.Timestamp with the Time of the EventFields. This will always identify correctly, whether the event was generated before or after the CallResponse.

This has been observed similarly in the Acknowledge, which could be updated in the same manner to resolve such time sync issues.

Additional Information

Other solutions which are not working:

  • Determining/calculating time diff is not possible, as the clock may further shift during the test
TagsNo tags attached.
Files Affected

/maintree/Alarms and Conditions/A and C Base/Refresh/Test Cases/initialize.js
/maintree/Alarms and Conditions/A and C Base/Refresh/Test Cases/initialize2.js
/maintree/Alarms and Conditions/A and C Base/Refresh/Test Cases/Test_001.js
/maintree/Alarms and Conditions/A and C Base/Refresh/Test Cases/Test_007.js

Relationships

related to 0008558 closedArchie Miller A and C Refresh stops without running all test scripts and indication of it 
related to 0008565 closedArchie Miller A&C scripts printing misleading skip messages or marking tests as passed which are not run 

Activities

Paul Hunkar

2023-01-03 18:21

administrator   ~0018399

The test scripts were supposed to be updated to always just use the device time stamps
The time on the CTT does not matter - they should not come into play in any manner
The EventId / ConditionId is enough to unique identify something - the timestamp of the alarm going active is enough to see if it is the same alarm I just sent a command to or if it has reactivated

Paul Hunkar

2023-02-18 22:49

administrator   ~0018767

reviewed changes agreed to changes, closed issue

Issue History

Date Modified Username Field Change
2023-01-03 14:22 Alexander Allmendinger New Issue
2023-01-03 18:21 Paul Hunkar Note Added: 0018399
2023-02-06 15:27 Paul Hunkar Assigned To => Archie Miller
2023-02-06 15:27 Paul Hunkar Status new => assigned
2023-02-06 23:46 Archie Miller Relationship added related to 0008558
2023-02-06 23:46 Archie Miller Relationship added related to 0008565
2023-02-07 00:31 Archie Miller Status assigned => resolved
2023-02-07 00:31 Archie Miller Resolution open => fixed
2023-02-07 00:32 Archie Miller Files Affected => /maintree/Alarms and Conditions/A and C Base/Refresh/Test Cases/initialize.js
/maintree/Alarms and Conditions/A and C Base/Refresh/Test Cases/initialize2.js
/maintree/Alarms and Conditions/A and C Base/Refresh/Test Cases/Test_001.js
/maintree/Alarms...
2023-02-18 22:49 Paul Hunkar Fixed in Version => 1.03.502
2023-02-18 22:49 Paul Hunkar Target Version => 1.03.502
2023-02-18 22:49 Paul Hunkar Status resolved => closed
2023-02-18 22:49 Paul Hunkar Note Added: 0018767