Time Support

This ticket is to describe the architectural issues associated with using Time in the control system. The main requirements are:

• SKA1-SYS_REQ-3557: All client devices and applications that require synchronise telescope network time shall comply with the Network Time Protocol version 4 standard, RFC 5905.
• New requirements in ECP-190005 - Adoption of L1 requirements from OCD Rev03 that:
  • SKA1-OPS-73: SKA1_Common, SKA1_Low and SKA1_Mid shall be able to express timings in Scheduling Blocks in UTC, Local Sidereal Time and/or in local time for the SKA1_Low and SKA1_Mid telescopes.
  • SKA1-OPS-74 The SKA Observatory shall apply leap second corrections to all its timing and clock systems. It will be possible to apply this correction either automatically or manually.
  • SKA1-OPS-75 SKA1_Low and SKA1_Mid shall continue observing and operating normally across leap seconds. No Scheduling Block should commence at a time coincident with a leap second.

Internally, most of this can be achieved if we ensure we use routines derived from the SOFA Time Scale and Calendar Tools - for example see Other Implementations of the SOFA Library and, importantly, astropy.time, which is based on ERFA, one of the direct implementations mentioned on the SOFA web pages.

In addition, it is important to be able to test the system, as far as possible, at specific times and dates. Thus I propose an internal software test requirement that:

• For testing, the time used by the control system can be offset from the actual time by a fixed amount and be programmed to run at a different rate.

In principle could be done by defining some global variables for the duration of the test (potentially implemented as a configuration file, environment variables) or similar to specify, for example, an Epoch, a Test Epoch that this corresponds to, and a positive rate. The test time would then be t'=TestEpoch+(t-Epoch)*rate = t*rate + TestEpoch - Epoch*rate. The former formulation just avoids subtracting two large numbers, whereas the latter makes it clear there are only two independent variables.

Some architectural concerns may be:

• When it is acceptable to use system time rather than control system time.
• How to implement getting the current control system time.
• How to indicate if there is a time locking issues.
• Implementation for languages other than Python.
• Interface mechanisms - currently most Tango interfaces implement time as strings, and wire protocol interface are offsets from an Epoch. In a number of cases, these need to be described more carefully.