Clock Synchronization and Timestamping of Data on Acquisition at the Wellsite: Guidelines and Recommendations

Due to the nature of drilling operations, there are several companies collecting data at the rig. The data acquisition system of each company applies its own timestamp to the data. Subsequent aggregation of data (for example, in a data repository) relies on synchronized timestamps applied to the different data sources to correctly collate the data. Unfortunately, synchronized timestamping is rarely achieved. In this paper, we document the different sources of errors in timestamping of data and provide guidelines to help mitigate some of these causes. There are many reasons for the unsynchronized timestamping of data from different sources. It can be as simple as clock synchronization at the rig; each data-providing or -producing company has an independent clock. It can also be due to where the timestamp is applied, for example, at the data source or on data reception. Additionally, it can be due to how the timestamp is applied—at the start of the sampling interval, the midpoint, or the end. Some of the communication methods used at the wellsite, such as mud pulse telemetry that is used to transmit downhole measurements to the surface, have a high, nonstationary latency and the actual acquisition time may vary significantly from the received time. Not correcting the reception time for the transmission delay can result in erroneous timestamping of downhole-acquired data. Timestamping of derived data (data computed from two or more sources) is problematic if the data sources are unsynchronized. Synchronization of clocks within the data acquisition network is therefore extremely important. The resolution of time synchronization depends on purpose; motion control of the rig equipment (for example, the hoist) demands high-resolution timekeeping. However, for the purposes of timestamping acquired data, synchronization to a network time server (a computer with access to a reference clock that distributes the time of day to its client computers over a network) with a resolution of 1 millisecond is sufficient. The issue is agreeing on the common source of time (the reference clock) and agreeing on the passage of time signals through network firewalls. Timestamping is a more involved matter, calling for agreement on standards and, if possible, a computer-interpretable description of the time-related information associated with real-time data. In this paper, we describe in some detail sender vs. receiver timestamping, the downhole to surface timestamp chain, and times