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

Digital connectivity at the wellsite has been a significant issue due to the number of parties involved (operators, drilling contractors, service companies, etc.), the lack of consistency between their systems, the remoteness of locations from any network, and the general lack of guidance on what is required. The introduction of drilling systems automation—the process automation of drilling—seems to have been initiated in the mid-2000s as described, for example, by Iversen et al. (2009). The recognition of the efficiency benefits and impact on drilling practices are described in Macpherson et al. (2013). The impact on rig systems is described in Daireaux et al. (2019), and continued development has led more recently to research into autonomous systems, such as described in Mihai et al. (2022).

Systems automation requires tight control of time; systems delivering set-point sequences for equipment (sequences of values used by equipment controllers) need to be operating according to a common time reference and need to follow agreed-upon guidelines when placing timestamps on data records. Clock synchronization becomes critical to ensure high-speed coordinated motion of independently controlled drilling equipment (Park and Kim 2016). Here, a clock refers to a device that measures and indicates time.

There are industry standards to synchronize time at different precision levels, such as network time protocol (NTP) vs. precision time protocol (PTP). The relative performance of these protocols has been evaluated in several papers (e.g., Pacner et al. 2013; Lei et al. 2009). All time-of-day (TOD) clocks at the wellsite should be synchronized. These are computer or processor clocks used in communications and for timestamping (applying a digital record that indicates when the attached measurements occurred). For instance, Bjørkevoll et al. (2010) describe the importance of time synchronization of the multiple actions taken when starting mud circulation in a managed pressure drilling operation with very tight geo-pressure margins, as drilling fluid compressibility and gel breaking after a connection could cause a pressure pulse that exceeds the fracturing pressure of the openhole formation.

In the digitalization of drilling operations, running mathematical models of the drilling process in real time is an essential enabler for several drilling automation solutions. Nevertheless, such models need to be calibrated using actual measurements. Bjørkevoll et al. (2015) discuss the many pitfalls associated with time discrepancies between different data sources while attempting to automatically calibrate hydraulic models.

The consequences of nonsynchronized clocks can affect real-time drilling operations and can significantly affect after-the-event audit exercises (root-cause analyses). As pointed out by Cayeux and Daireaux (2009), the synchronization of clocks between different systems is critical when gathering measurements from real-time sensors. They advocate the use of automatic clock-synchronization systems or, if these are unavailable, manual synchronization procedures before the start of drilling operations.

The increased use of remote operations centers in real time—see, for example, Mathur et al. (2020)—also demands that clocks at the wellsite are synchronized to a global timing source, such as a global positioning system (GPS), and measure TOD with respect to a standard reference, such as coordinated universal time (UTC). The relationship between GPS and UTC is described in some detail in the section GPS and UTC Reference Time.

An example of the importance of time synchronization of all networked clocks at the wellsite is rather obvious: At any time of day, the drill bit and any downhole sensors, such as directional, hydraulic, mechanical, dynamic, and downhole formation evaluation measurements, are at a particular depth in the borehole. This TOD-depth relationship is quite important as it forms the basis of moving between time and depth (either measured depth or true vertical depth). If two separate clocks on the system are set differently, then two different timestamps for various measurements may be associated with the same depth. A downhole measurement of a formation parameter (such as gamma ray) may be associated with an incorrect rate of penetration (ROP) or other surface parameter. The error can be quite large. For example, it is becoming common to drill mile-a-day wells in the unconventional plays in the United States (Livingston et al. 2016). This is an average drilling rate of 220 ft/hr (67 m/h), and a 1-minute error in two clocks will result in a 3 2/3 ft (1.2 m) error in the relationship between measurements.

While it is common to manually resolve such discrepancies, this is problematic at best in an automated environment. Another serious issue is the use of analytics on data that are incorrectly related in time or depth. As described by Isbell et al. (2022), it is critical to place data at the same time, and relating surface and downhole data can be particularly difficult. The TOD clocks on surface and downhole operate in different thermal and vibration environments leading to relative clock drift. While this can be compensated for when tool memory is recovered when on surface, it is not a trivial issue in real time; dealing with clock resets and drifts at the same time in high-shock and -vibration drilling environments could be challenging to overcome. Dashevskiy et al. (2008) examined this problem and its solution in some detail.

In this paper, we explore the clock synchronization and record timestamping issue in detail, developing guidelines and recommendations. As mentioned at the start of the introduction, drilling systems automation in multiplayer environments is only possible if a common time measurement reference is agreed to and followed by all parties.

There are primarily two areas of concern related to accurate time measurement, which are timestamping and time synchronization. When and where the data are timestamped is just as important as keeping all the clocks of the acquisition systems synchronized. Timestamping and time synchronization requirements depend on what the data involved in transfer between systems are being used for. If the integration between two systems is for machine-to-machine integration, typically in motion control, the synchronization is at the microsecond level. If the integration is for process control, the synchronization can be at the millisecond level. If the integration is for offline advisory computation, then the synchronization can be at the second level.

One of the issues facing clock synchronization and timestamping of data at the wellsite is that many parties are involved. Each of these parties has their own sensors and acquires their own data. The data are then transmitted between parties, perhaps aggregated in some form, and then transmitted to yet another system. This is a distributed data acquisition system and can be quite complex. Potentially, each node in the network has its own reference clock. As an example:

• One data provider makes formation evaluation measurements downhole. These are transmitted to the surface without a timestamp due to the low bandwidth of the communication system. This data provider appends a timestamp when the data packet is received, compensating the timestamp for transmission delay, and sends the packet onwards.

• Another data provider makes surface sensor measurements. These come from various points on the rig and are accumulated in records to which the data append a timestamp. As these measurements are judged to be “instantaneous,” the timestamp is not adjusted for any sampling delays.

• Yet another data provider delivers information on mud and formation properties (mud-logging information). This operator may attempt to correct the measurement time for fluid circulation time from the bottom of the borehole (the “bottoms-up” time) but is more likely to use the “bottoms-up time” to correct the depth of the sample and then apply an incorrect timestamp to the sample.

• Finally, all other data providers at the wellsite, such as managed pressure drilling engineers, drilling engineers, cementing engineers, completions engineers, etc., all have their own computer networks with independent TOD clocks. Each uses their own estimate of time when timestamping data.

This is the current situation at the wellsite, and it leads to opportunities for error and limits process automation and interoperability (the ability to plug-and-play computer systems and networks and share data). There is a real need for time standards at the rigsite, and we develop guidelines and recommendations for those standards in this paper.

As mentioned previously, clocks at the wellsite should be synchronized to a global timing source, such as GPS, and measure TOD with respect to a standard reference, such as UTC. GPS time and UTC time are actually two distinct notions, as the first refers to time defined by a physical clock and the second is defined based on the rotation of the Earth (i.e., there are 24×60×60 = 86,400 seconds per day on average over 1 year, between two consecutive observations of the sun at its highest position in the sky at a given meridian).

The rotation of the Earth is not constant and cannot be predicted over a long period of time (Arias et al. 2003). In contrast, the international atomic time (TAI) is defined by the weighted average time measured by more than 450 atomic clocks around the world. GPS satellites also use atomic clocks. Due to their orbital distance to Earth, approximately 20 200 km from the reference world geodetic datum (WGS84), their clocks are subject to the effect of a relatively high speed compared to the Earth’s surface, which needs to be compensated for using special relativity (ticking 7 µs/D slower than clocks on the WGS84 spheroid), and the effect of a lower curvature of the space-time continuum than on Earth, meaning that GPS clocks tick 45 µs/D faster than clocks on WGS84. The overall compensation of 38 µs/D (van Diggelen 2009) to account for special and general relativity is necessary; otherwise, the GPS system would drift by 10 km/d (Andersson and Comer 2021). In practice, GPS time is continuous and exactly 19 seconds behind TAI.

Because of the variations in the Earth’s rotational speed, UTC time needs to be compensated compared to TAI at irregular timing. This is done by adding or skipping a leap second when the difference between UTC and TAI exceeds 1 second. Between 1972 and 2017, there have been added 27 leap seconds on top of the 10-second initial difference with TAI. GPS time can be accessed using a GPS receiver from the radio signals emitted by the GPS satellites. UTC time is broadcasted by terrestrial antenna across the world. When a leap second is added or skipped, there can be a discrepancy between a time reference based on UTC broadcast or GPS satellites. As of 2023, UTC time is 37 seconds behind TAI, and GPS time is ahead of UTC time by 18 seconds (see Fig. 1 ).

An acquisition timestamp is a timestamp applied when a measurement is made. It is also referred to as a source timestamp. If two devices are communicating, then the sending device may add its timestamp to a data packet (the sending timestamp), and the receiving device may also add its timestamp to a data packet (the receiving timestamp). In this simple scenario—and it may be much more complex when data are routed between multiple devices—there is obviously an opportunity for error if any of these timestamps is overwritten or misinterpreted.

Data measurement and acquisition systems will typically apply a timestamp to measured data. One issue is that these timestamps are typically attached when the data are recorded to media (rather than acquired), and so may include a delay due to conversion from electrical tension or current to a physical unit. These timestamps may also include data packaging delays, for example, if a row of data from different sensors is assembled and then recorded with the same timestamp.

Data aggregation systems (which are receiving devices) at the wellsite or off-site will expect to receive timestamps and will record these sender timestamps. However, typical rig instrumentation systems, such as the electronic data recorder (EDR)—described by Pastorek et al. (2019)—and pit volume totalizer (PVT)—described by Fraser et al. (2014)—will timestamp data on receipt.

Most instrumentation systems will read data from other service providers through different protocols, such as Wellsite Information Transfer Standard [described by Jantzen et al. (1989)], Modbus [described by Swales (1999)], and Open Platform Communications (OPC) [described by Mahnke et al. (2009)]. The Wellsite Information Transfer Standard and Modbus protocols typically do not provide a timestamp of data acquisition. While OPC has timestamp values, most devices do not send timestamps, so the OPC server will add a server timestamp, not an acquisition timestamp.

During process control, machine-to-machine interactions do not send timestamps; all data are acted upon immediately. Typical data exchange is from 1 millisecond to 100 milliseconds. When data are stored for further processing, the data then get timestamped.

Often, it is not instantaneous values that are transmitted by a data provider but a statistical characteristic over a sample of multiple values in time or depth. Typical statistical values are average, minimum and maximum, standard deviation when the data sample is supposed to follow a normal distribution, or several quantiles in case of a non-Gaussian data distribution. The data sample can be based on a moving time window, a moving depth window, or a defined number of data points.

In the case of a data sample based on a time window, the question of timestamping can be resolved by indicating either the timestamp at the start or at the end of the time window and the timespan of the time window. For example, downhole pressures from an along-string measurement tool (Reeves et al. 2011) that transmits data over a wired pipe (Veeningen 2011) may be provided as average values for a constant time window of a couple of seconds. It is not important to standardize whether the timestamp shall be at the start, the middle, or the end of the data sample if the utilized convention is made available; that is, the data provider indicates the position of the timestamp relative to the data sample time window and the duration of the time window. An example of a signal that is often calculated based on a depth window is the average ROP, which can be an average ROP for drilling 1 ft, 1 m, and so on (Goncalves et al. 2017). Here, the only certain timestamp is the time by which the value is provided. The duration for arriving at the value can be rather complex, especially if a necessary condition for estimation of the signal is not respected for some time, such as in the example of the average ROP when the bit is lifted off the bottom. Several alternatives may exist, including but not limited to the accounting for the average ROP stops when the bit is lifted and resumes when the bit gets on the bottom again or the average ROP decreases slowly to reach zero when the bit is lifted and resumes slowly when the bit returns to the bottom. Again, there are no solutions that shall be considered as better than others. It only matters that the data provider is transparent about which method is used.

Yet another possible way to define a data sample to produce statistical characteristics is simply to gather a defined number of individual data samples. There are many reasons why such a method is used and one of them is related to the sparsity of data values. For instance, it is important to monitor the evolution of mechanical friction because it is an indicator of potential deteriorations of the downhole conditions (Cayeux et al. 2012). Cayeux and Daireaux (2009) describe a method where statistical estimation of mechanical friction factors over a time window (e.g., average and standard deviation) is used to generate warning signs of changes in the downhole conditions. To estimate an average and standard deviation of the mechanical friction factor, there shall be a sufficient number of estimated values during the time window. In practice, the mechanical friction factor may only be estimated when there is a movement (rotation or sliding) and the bit is off the bottom. The occurrence of such conditions may be rather seldom on some occasions (while drilling with low ROP, for instance) or rather frequent, such as while tripping. Some of the samples may also be rejected after some time because the conditions under which the first ones were measured are not compatible with the conditions for the latter samples. Fig. 2  shows an example of an automatic classifier for drilling activities. It classifies, among other things, when there is rotation off-bottom, pick-up, and slackoff. The last bit depth, the arithmetic means for all acquired parameters (only a few are shown on Fig. 2 ), the timestamp at the end of the time window, and the duration of the classified drilling activity are all reported by the classifier. The conditions for classifying a rotation off-bottom are that the bit is not in contact with the bottom of the hole, the topdrive rotates at a steady speed, and there is no axial movement. Similarly, the conditions for a pickup (respectively, a slackoff) are that the bit is off-bottom, the topdrive rotation is zero, the top-of-string velocity is strictly positive (respectively, strictly negative), over a threshold in absolute value and with a standard deviation lower than a minimum value. Among the averaged parameters, there is the drilling fluid density. So, in the case of an estimation of an average mechanical friction factor, if there has been a displacement to a new drilling fluid, here characterized by a different drilling fluid density, while collecting the data sample, the mechanical friction factor measurements made with the previous fluid are no longer compatible with the measurements made after the new mud has been displaced. The timestamp shall obviously be the time by which the statistical characteristic has been generated; however, the timestamp itself is insufficient to properly interpret the provided value. The data provider shall, in addition, describe the mechanisms used to construct the data samples that are used to calculate the statistical characteristics.

Some data may not be accessible directly but rather be the result of a calculation. For instance, when the only accessible measurement is a position, velocities and accelerations must be derived through a series of position values and their associated time intervals. This concerns any measurements that involve an encoder. For that matter, the stroke counter of a mud pump is in fact an encoder with a very low resolution. The speed calculation can either use a central difference or a one-sided difference:

where $vi$ is the derived velocity and $xi+1$⁠, $xi$⁠, and $xi−1$ are, respectively, three position values taken at time $ti+1$⁠, $ti$⁠, and $ti−1$⁠. Here, the term “position” can refer to different physical quantities that may be a frequency when referring to pump rate, a length as with a block position, or an angle such as with a topdrive shaft orientation. In all three cases, the timestamp of the derived velocity is not synchronous with the last position measurement. For the central difference, the timestamp of the derived velocity should be the timestamp of the intermediate position measurement (i.e., $t=ti$⁠), the value of which actually does not appear in the central-difference calculation method. For the two other cases, the timestamp should be in the past compared to the most recent position measurement [i.e., $t=ti−12(ti−ti−1)$ for the backward difference method and $t=ti+12(ti+1−ti)$ for the forward difference method.

Similarly, acceleration calculations from position measurement are obtained from a central difference method:

where $ai$ is the derived acceleration. Here, also, the timestamp of the derived acceleration shall be in the past compared to the most recent position measurement (i.e., $t=ti$⁠).

We have seen that for both velocities and accelerations that are derived from position data, their timestamp shall always be in the past. Also, timestamping depends on the time interval between each of the position data. For position data related to an encoder, the time difference between two measurements is not constant during acceleration, and therefore the delay embedded in the timestamp of those derived values is also not constant. Unfortunately, it is common that timestamps associated with these values are the ones of the time at calculation or when transmitted (i.e., a value that is in the future of the most recently acquired position data). For fast-paced encoder measurements, erroneous timestamping may be important for computer systems but are practically unobservable for humans. However, for processes that provide encoder position with long delays, erroneous timestamping on derived velocities and acceleration can lead to inconsistencies that are even visible to human beings. For example, it is not uncommon to observe that the pump pressure increases even though the pump rate is zero. This happens at low pump rates, because it may take several seconds before two or three strokes are counted; therefore, delaying substantially the arrival of the pump rate while the standpipe pressure, being a direct measurement, is not delayed in the same manner. The example of Fig. 3  could be explained by establishing circulation using a low pump rate, a mud pump speed calculation using the central difference method as explained in Eq. 1, and taking the provided value without considering its timestamping. The first reported flow rate is 133 L/min, which corresponds to about 7.2 SPM with a stroke volume of 18.5 L. If the position of the pump is such that it takes almost a full stroke before the proximity switch of the pump is triggered, then it will take almost 25 seconds before the speed can be calculated. Indeed, with such a mud pump speed, it takes 8.3 seconds between two strokes to be recorded, and this results in a delay of 3×8.3 = 24.9 seconds before the mud pump speed is calculated. The timestamping of the value is 8.3 seconds behind in time, but if the value is taken directly without considering its timestamping, then the situation described in Fig. 3  is obtained. If instead of the central difference, the forward or backward difference method were used to calculate the pump speed, then the delay would be between 8.3 seconds and 16.6 seconds, depending on the initial position of the pump. If the mud pump speed is timestamped, then it will be 4.15 seconds behind the current time.

There is also the problem of choosing which timestamp to use for calculated data. Data that are generated by a calculation usually depend on input signals and parameters. Here, the definition of a parameter is a value that is useful to identify a system. For instance, the mechanical friction factor can be considered a parameter for torque and drag calculations. Often, the input signals to the calculation are not all synchronized. The calculation process may perform a reinterpolation of the input signals to obtain consistent inputs, and in that case, it is logical to timestamp the outputs of the calculation relative to the common timestamp of the input signals. Such a strategy is confronted with the problem that the reinterpolation may need to take place relatively far in the past, if one of the signals arrives infrequently or has a high latency. Therefore, in many cases, the calculation process does not perform such reinterpolation and consumes the signals as they arrive. In that latter case, it may be unclear how to define the timestamp of the outputs. Should it be the timestamp of the oldest signal, the most recent signal, or anything in between? Here, again, transparency shall prevail: It is better that the calculation process indicates which strategy it uses with regard to the time processing of input signals and the timestamping of its outputs.

Another problem associated with calculated values is related to the parameters used by the process. Usually, the calibration of parameters takes place at a slower pace than the processing of input signals. Sometimes, the parameter calibration is made continuously, as, for example, with a Kalman filter (an optimal state estimator based on real-time system measurements; Welch and Bishop 1995). On other occasions, the parameter calibration requires specific conditions to exist, and these conditions may occur very infrequently. An example is when calibrating axial mechanical friction factors, it is necessary to have an axial movement without rotation while being off the bottom. For the sake of transparency, it is advisable that the calculation process indicates on which parameters it depends and that the timestamp for the calibrated parameters is available.

High-latency transmission is quite common in drilling operations. Correct timestamping is extremely important in situations where there is a significant delay between sending and receiving data. There are two example cases, which are (a) telemetered data from downhole to surface and (b) telemetered data between the rig and remote operations centers. These are quite separate, with their own challenges.

In the case of telemetering between the downhole and the surface, the downhole environment is quite different from the surface. It has higher temperature and higher vibration—a clock may run at a different rate downhole, and a clock downhole will diverge from a clock on the surface, as discussed by Dashevskiy et al. (2008). It is possible to build a downhole clock that will diverge slowly, say less than a millisecond over several days, but such a clock is prohibitively expensive for most operations. It is available for seismic-while-drilling operations where signal time is transmitted from downhole. For most measurement-while-drilling and logging-while-drilling operations using a real-time downhole telemetry system, downhole records are typically timestamped when received on the surface with a timestamp adjusted for the telemetry delay.

Estimating the telemetry delay is not trivial in some telemetry methods, such as mud pulse (Cayeux et al. 2018). The speed of data transmission depends on the compressibility, density, and temperature of the fluid (Cayeux 2023). For most drilling fluids, it is between 900 m/s and 1500 m/s, which corresponds to a time delay of 4–7 seconds for a 20,000-ft (6096-m) well. See Fig. 4  for the example time delay vs. depth.

The method of adjusting the surface timestamp so that data packets telemetered from downhole can be marked with a source timestamp is proprietary to each measurement tool company. This adjustment is often carried out in real time and then adjusted (or replaced) when the tool is recovered on the surface, memory dumped, and the downhole clock accessed and compared with the surface clock.

For long telemetry intervals, such as downhole to surface and wellsite to town, there may be considerable latency. High latency data should be timestamped at the source, rather than on receipt, so that data sets from different sources correspond in time. These data are often in packets (sometimes called frames). Generally, the timestamp of the data in the packet is the timestamp of the packet. This assumption is fine if the packet is timestamped at the source and the packet interval is the same as the data acquisition interval. However, it is worthwhile noting some potential issues due to the acquisition interval of the data differing from the packet rate.

If the acquisition interval is faster than the packet rate (for example, a measurement averaged at a 5-second interval and a packet sent every 30 seconds with only sample of the measurement), then the data are undersampled and potentially aliased at the receiver. In addition, because each individual data item is not timestamped in a packet, it is not possible for the user to know at which period within the packet the data came from. In our example, only every sixth value is sent, and it has six (equally valid) possible timestamps. Nevertheless, by convention, it assumes the timestamp of the packet (see Fig. 5 ).

Conversely, if the acquisition interval is longer than the packet rate, old values may be used to fill the empty data slot in the packet. This results in a stair-stepped output, which is quite confusing to downstream processing (and sore on the eyes).

The lesson is that timestamping should be (a) at the source or at both the source and the receiver, never at the receiver alone, and (b) transparent about measurement interval and packet interval so that logical choices can be made in downstream processing on how to handle time offsets between data sources.

Image data can represent a considerable interval of holes, especially at higher drilling rates. It is therefore important to know if the image is timestamped at the start of the interval or at the end. When the logging company processes the image internally, then this is typically not an issue, but in future, interoperability (essentially the real-time sharing of data among many parties) may result in image sharing in real time. In this case, each row of the image should be timestamped or the timestamping and sampling protocol be made transparent to the end user.

It has been noticed that some data are provided in a delta-encoded format in which, in a simple case, each provided data value is the difference from some base value, or from the previous value after reconstruction of its true value. It would be far simpler to provide the stream along with timestamps, but if the delta-encoded stream is provided, then it should be done in a transparent fashion, allowing the end user to reliably reconstruct the data stream, along with timestamps.

Time should be stored in UTC format, and location information (time zone) stored separately as metadata.

NTP (Mills 1991) is the standard that most systems use for time synchronization. Time synchronization typically uses a network time server as the source to synchronize a server on the rigsite and all other devices at the rigsite synchronize to this local server. An NTP server may use a variety of synchronization sources. They are defined by the reference identifier and can be based on GPS satellites, UTC broadcasts, or other sources. Regardless of the type of time source, an NTP server always uses UTC time, meaning that it must manage leap seconds when they are introduced. The NTP clock is halted for 1 second during a leap second event or would skip 1 second if a negative leap second should ever occur. The standard NTP protocol uses 64-bit timestamps at a resolution of 233 picoseconds. The NTP epoch is 1 January 1900 and therefore there will be a rollover of the timestamp on 7 February 2036. The accuracy of time synchronization with the reference clock depends on the stratum level (i.e., how many intermediates there are between the reference clock and the computer). Stratum 0 is the global reference clock itself. The maximum stratum level is 15, while 16 is reserved for clocks that are not synchronized (Cayeux et al. 2019). Also, if there is a large time difference between the computer and the NTP server, synchronization stops, and it is necessary to manually force the synchronization to restart. This can happen, for instance, when computers are stopped for some time such as when moving to another location for land rigs. As the stopping of time synchronization of the NTP server can happen unnoticed, it is important to have monitoring services to detect such incidents.

Motion control requires that the devices in the motion group are time synchronized locally and do not necessarily need to be synchronized to a global clock. Most post-processing systems will require all timestamped data to be synchronized to a global clock.

Motion control algorithms as used in machine-to-machine interaction require time synchronization to the microsecond level, while typical process control and advisory applications can work with millisecond-level synchronization.

PTP (Correll et al. 2005) is preferred to synchronize network clocks to the nanosecond and is typically mandatory for motion control drives. NTP is the typical standard for lower precision applications, and it is used to synchronize network clocks to a precision of 1 millisecond for process control and data acquisition.

Yet, the precision of the time synchronization depends on the topology and the load on the computer network, and delays of up to 100 milliseconds are possible (Cayeux et al. 2019). In many cases, a hybrid approach is used; NTP to synchronize a PTP grandmaster and PTP for other devices within the controls network.

Many machine control devices are either fully disconnected or behind firewalls that may prevent direct external time synchronization. Firewall rules must be added to allow for time synchronization protocols to go through. On fully disconnected rigs, a GPS module is used that provides synchronized time.

A summary of time synchronization and timestamping guidelines, as described in this section, is shown in Table 1 .

On a typical land rig, the wide area network (WAN) connection is via a very small aperture terminal or wireless communication protocol (for example, 4G) connected to a router that resides on the trailer side of the rig. The control system, which includes the controller, input/output, and process automation, is on the substructure side of the rig. The network connectivity between the trailer side of the rig and the substructure side is a pain point on most rigs. Some rigs provide redundant fiber across the two sides, but on most rigs, it is a wireless link or a single copper cable that routes along power cables and is susceptible to noise and physical damage.

When it comes to time synchronization, most rigs will use the router as the local time synchronization server, which synchronizes to a global clock over the WAN connection. All other devices on the rig will synchronize to the local time server. See Fig. 6  for a typical land rig network configuration showing how time synchronization devices are located.

Land rigs tend to change location frequently, which further imposes a burden on clock synchronization. The rig owner (the drilling contractor) must define a procedure for rig startup on a new location after a rig move to ensure that the time synchronization is running. All other parties should synchronize to the rig network time server using a procedure defined by the drilling contractor.

To share a time server among all parties on the rig, the assumption is that the currently independent networks will be bridged in some way. As automation and interoperability levels increase, the need for network bridging will become important, hence the requirement for bridging should not be an undue burden. There are different ways of bridging networks either at the data link layer or the network layer of the Open Systems Interconnection model. The Open Systems Interconnection model is a conceptual model for system interconnection. It is composed of seven nested layers, in order from the deepest to the shallowest layer as physical, data link, network, transport, session, presentation, and application (Stallings 1987). The specific implementation is beyond the scope of this paper. However, it is important to know that any bridging introduces cyber-security implications that must be addressed.

The International Association of Drilling Contractors cyber-security committee is defining a network segmentation recommendation that is working to separate the control system, the business network, and third-party connectivity. There are several standard network segmentation architectures documented in the published literature. Several vendors have published white papers on securing the plant environment (see CISCO 2022, for example). The drilling contractor should create a rig network segmentation design that should allow for other parties to reach a rig time server and synchronize time to this server. The recommendation also requires a Layer 3 firewall. Our recommendation is to include deep packet inspection to ensure that only time synchronization packets are allowed.

The guidelines and recommendations described above can be summarized in the following guidelines covering this broad topic. For usefulness, these guidelines tend to specific recommendations (for example, that there is one master clock) but place that recommendation within broad guidelines (for example, who provides it and how it is used).

There should be one master clock (the rigsite time server), synchronized to a global time source (i.e., a clock at Stratum 0 such as a GPS clock or a UTC radio broadcast clock). This may be provided by the drilling Ccntractor. All participants on the rig should synchronize to this time server to ensure a common clock. For rigs that do not have any WAN connection and are fully disconnected, install a GPS receiver and synchronize time using this source.

Any zone that is collecting data and has the potential of losing connectivity to the rigsite time server (the master clock) should have a local time server. On land rigs, the rig floor side and trailer side must have their own time servers due to the unreliable nature of the cross-location link. Each zone should provide a primary and secondary time server for redundancy. All data acquisition systems must configure both servers.

Each data acquisition system must run a time synchronization monitoring service that ensures that the time synchronization is running and alerts the operator upon service failure.

Drilling rigs, especially land rigs, move often. They may end up with the local server out of synchronization by a large margin when it comes up on the new location, at which point NTP will not synchronize and will need a manual forced synchronization. The drilling contractor must define a procedure for rig startup on a new location after a rig move to ensure that the time synchronization is running. In addition, when rigs move countries, or the WAN connection provider is changed, ensure that your global time server is still accessible.

Any other parties deploying computer systems and networks at the rigsite, and communicating or acquiring data, should define a procedure to configure time synchronization upon arrival at the rig.

Ensure local firewall settings, and the settings of your cloud provider’s firewall, and allow NTP protocol through. This applies to all parties at the wellsite.

All timestamps must be stored in UTC format, with location information stored separately as metadata. Any data that are being sent to instrumentation systems or process control systems should be sent with a timestamp. All data aggregation systems must use the source timestamp.

These guidelines are quite simple, but as the text of the paper has attempted to show, not following them leads to systems that do not communicate correctly and to incorrectly aggregated data. In real-time systems in particular, this leads to data that cannot reliably be used in process automation, and to analytics that can present erroneous decisions.

In the discussion above, it is advocated that providers of real-time signals describe, if possible, in a computer-readable format, the background information related to the reference time source, the transmission of information, and the timestamping process. This can be achieved by publishing a semantical description associated with the signals. One possible method for describing the meaning of information is semantic graphs. This concept was introduced in the 1950s and 1960s during the pioneering research efforts on symbolic artificial intelligence (Lehmann 1992; Simmons 1963).

Facts (i.e., true assertions) are expressed as a triplet, where the first element is an individual, the second element is a verb, and the last element is also an individual. Such a triplet represents a sentence of the kind “subject verb object.” An individual is an instance of a noun that is identifiable. Here, the word “instance” refers to the instantiation concept used in object-oriented programming. A noun is a generic term that describes a set of individuals. Nouns can be related to each other using specialization/generalization (i.e., the concept of inheritance in object-oriented programming). A noun has a list of attributes that define the characteristics of that noun. Verbs define a relation between individuals. They are also related to each other using specialization/generalization relationships.

In the Drilling and Wells Interoperability Standards (DWIS), a subcommittee of the SPE Drilling System Automation Technical Section, the root of all nouns is called DWISNoun and the superclass of all verbs is DWISVerb (Cayeux et al. 2023). Note that the verb IsA, a subclass of DWISVerb, can relate an individual to a DWISNoun. A description of the semantic vocabulary used to express the time characteristic of real-time signals can be found in the  Appendix.

Let us suppose that the standpipe pressure (SPP) is measured by the rig control system and acquired by an EDR. The rig control system resides in a network segment that has its own NTP server. This NTP server is synchronized to the NTP server of the rig, which has a GPS reference clock. The EDR is in another network segment, which also has an NTP server. The latter is also synchronized by the NTP server of the rig. Fig. 7  illustrates the possible network, NTP server, and clock configuration for the acquisition of the SPP signal at the rigsite.

The time-dependent information for an SPP real-time signal could be described like this:

• SPP#1 IsA Measurement

• SPP-Signal#1 IsA DynamicDrillingSignal

• SPP#1 HasDynamicValue SPP-Signal#1

• GPSClock#1[Stratum:0] IsA Clock

• NTPServerRig#1 IsA SynchronizationGroup

• NTPServerRig#1 HasReferenceClock GPSClock#1

• NTPServerRigControlSystem#1 IsA SynchronizationGroup

• NTPServerRig#1 IsSynchronizationGroupInput NTPServerRigControlSystem#1

• RigControlSystemClock#1 IsA Clock

• RigControlSystemClock#1 IsSynchronizedBy NTPServerRigControlSystem#1

• SPP#1 HasSourceClock RigControlSystemClock#1

• NTPServerElectronicDataRecorder#1 IsA SynchronizationGroup

• NTPServerRig#1 IsSynchronizationGroupInput NTPServerElectronicDataRecorder#1

• ElectronicDataRecorderClock#1 IsA Clock

• ElectronicDataRecorderClock#1 IsSynchronizedBy NTPServerElectronicDataRecorder#1

• SPP#1 HasAcquisitionClock ElectronicDataRecorderClock#1

In another example, a downhole pressure measurement is taken by a downhole sub and transmitted by mud pulse telemetry to an EDR. The EDR is in its own network segment, and the NTP server is synchronized to the NTP server of the rig. The downhole mud pulse telemetry system has its own clock, which is synchronized before running in the hole to an NTP server residing in a network segment for the directional drilling company. The NTP server of the directional drilling company is synchronized to the rig NTP server. However, the downhole clock is not transmitted by the telemetry system. The directional drilling company acquires the downhole pressure and applies a correction to the timestamping before passing the value to the EDR. The rig NTP server has a GPS clock reference. A possible description of the various components involved in the timestamping of the downhole annulus pressure measurement is shown in Fig. 8 .

A description of these facts follows:

• AnnulusDownholePressure#1 IsA Measurement

• AnnulusDownholePressureSignal#1 IsA DynamicDrillingSignal

• AnnulusDownholePressure#1 HasDynamicValue AnnulusDownholePressureSignal#1

• GPSClock#1[Stratum:0] IsA Clock

• NTPServerRig#1 IsA SynchronizationGroup

• NTPServerRig#1 HasReferenceClock GPSClock#1

• NTPServerRigControlSystem#1 IsA SynchronizationGroup

• NTPServerRig#1 IsSynchronizationGroupInput NTPServerRigControlSystem#1

• NTPServerElectronicDataRecorder#1 IsA SynchronizationGroup

• NTPServerRig#1 IsSynchronizationGroupInput NTPServerElectronicDataRecorder#1

• ElectronicDataRecorderClock#1 IsA Clock

• ElectronicDataRecorderClock#1 IsSynchronizedBy NTPServerElectronicDataRecorder#1

• AnnulusDownholePressure#1 HasAcquisitionClock ElectronicDataRecorderClock#1

• NTPServerDirectionDrilling#1 IsA SynchronizationGroup

• NTPServerRig#1 IsSynchronizationGroupInput NTPServerDirectionDrilling#1

• DirectionalDrillingClock#1 IsA Clock

• DirectionalDrillingClock#1 IsSynchronizedBy NTPServerDirectionDrilling#1

• PWDClock#1[LastSynchronizedTime: xx] IsA Clock

• ADHP#1 IsA Measurement

• ADHPSignal#1 IsA DynamicDrillingSignal

• ADHP#1 HasDynamicValue ADHPSignal#1

• ADHP#1 HasSourceClock PWDClock#1

• PWD#1 IsA MeasurementDevice

• ADHP#1 IsMeasuredBy PWD#1

• MudPulseTelemetry#1 IsA TransmissionLine

• ADHP#1 IsTransmissionInput MudPulseTelemetry#1

• ReceivedADHP#1 IsA Measurement

• ReceivedADHPSignal#1 IsA DynamicDrillingSignal

• ReceivedADHP#1 HasDynamicValue ReceivedADHPSignal#1

• ReceivedADHP#1 IsTransmissionOutput MudPulseTelemetry#1

• ReceivedADHP#1 HasAcquisitionClock DirectionalDrillingClock#1

• TimeCorrection#1 IsA TimeEstimationAtSource

• ReceivedADHP#1 IsTransformationInput TimeCorrection#1

• AnnulusDownholePressure#1 IsTransformationOutput TimeCorrection#1

Many other examples could be possible using the same vocabulary. This semantic network approach is capable of describing the relationships in the clock synchronization and timestamping guidelines, which then renders these guidelines machine-interpretable.

Using the semantic vocabulary, it is possible to express facts related to various drilling real-time signals and especially details about their relation to time. This offers a transparent way to describe the dependence on time of real-time signals. The semantic facts are computer interpretable, therefore allowing for algorithmic solutions to be developed without the necessity of involving manual configuration by human beings. The advantage of using a method based on semantic graphs compared to using metadata descriptions is the possibility of describing situations that may not have been thought of in the first place. This is because the semantic graph method is similar to defining a language, and with a language, there are limitless possibilities to describe information. However, the drawback of the method is that it adds more complexity on the interpretation side.

Both clock synchronization of data networks and consistent timestamping of data records on these networks are important to enable accurate data communication. This accuracy is required for the implementation of systems automation (process automation), especially as multiple parties are involved, in real time, at the wellsite.

Applying a few principles for managing time at the rigsite can remove most of the stumbling stones associated with timestamping of drilling real-time data. These include using a master clock at the rigsite. Network segments that can be isolated from the master clock shall have their own local time server that can be synchronized with the master clock when possible. This includes service companies that are connected to the drilling operation in an intermittent fashion. Timestamping shall use the UTC time reference, and it should be possible to keep track of the timestamp at the source and the timestamp when data are acquired.

There are many different problems related to timestamping of real-time data. Some are associated with the generation of data, such as with derived or calculated data. Others are caused by the particularities of telemetric solutions, as for downhole measurements. In all cases, transparency about which assumptions and methods are used for the time management of the signal is of prime importance. A partial vocabulary dedicated to the description of time-related information has been described. This vocabulary can be used to define facts about the relation of drilling real-time signals to time. The vocabulary is the basis for describing the meaning of signals using semantic graphs. This allows for computer-interpretable solutions, therefore removing the need for manual configuration.

Clock: A clock is a device to measure and indicate time.

Data compression: Data compression is defined in information theory as a transformation of binary information into a form that requires fewer bits than the initial representation.

Delta encoding: Delta encoding is a method to transmit or store data in the form of the differences with preceding values in a sequence representing the time evolution of that particular data.

Metadata: Metadata are data that provide information about other data but not on the actual content of these other data.

Time: Time is the continued sequence of events that happens in an irreversible way from past to future as stated through the second law of thermodynamics. The notion of time is observer dependent as stated by the theory of relativity.

Transparency: In the context of this paper, the closest definition of transparency is the one from ethical behavior (i.e., parties operate in such a way that it is easy for others to see what actions are performed).

In this appendix, the vocabulary related to the description of clocks and the transmission and transformation of drilling real-time signals is provided. The vocabulary description begins by defining general concepts related to drilling signals before moving on to specific definitions.

A DrillingDataPoint represents a drilling signal and is a direct subclass of DWISNoun.

A DrillingSignal is also a subclass of DWISNoun. It is used to store the actual value of the drilling data. A subclass of DrillingSignal is DynamicDrillingSignal, which has two attributes:

• TimeStampAtSource: This is a UTC date-time value corresponding to the time at which the value has been taken.

• TimeStampAcquisition: This is a UTC date-time value at which the value has been acquired by the data acquisition system.

The verb HasValue is a subclass of DWISVerb and can take a subject from DrillingDataPoint and an object from DrillingSignal.

DrillingDataPoint has several subclasses including Measurement, which is reserved to describe actual measurements, meaning that the value of the associated DrillingSignal has been measured with a measurement instrument.

A Clock inherits directly from DWISNoun. It has the following attributes (Cayeux et al. 2019):

• LeapSeconds: An integer value indicating the number of leap seconds compared to TAI, not including the initial 10-second difference between TAI and UTC.

• Stratum: A positive integer value between 0 and 16 that indicates the stratum level of the clock compared to the reference clock; 16 is reserved to indicate that the clock is not synchronized with a reference time source.

• NetworkSynchronizationLatencyAverage: An estimation, in decimal seconds, of the average latency between the reference clock and this clock.

• NetworkSynchronizationLatencyStandardDeviation: An estimation, in decimal seconds, of the standard deviation of the latency between the reference clock and this clock.

• Resolution: A decimal second value that represents the resolution of the clock.

• LastSynchronizedTime: The last time the clock has been synchronized with a reference clock.

• Maximum Fluctuation: The maximum fluctuation of the clock per unit time after the clock has been synchronized with a reference clock. It is a fractional value (i.e., second/second).

A DrillingDataPoint can be related to a Clock that is used to inform the attribute TimeStampAtSource of an associated DynamicDrillingSignal. The verb HasAcquisitionClock relates a DrillingDataPoint with a Clock to inform about which clock is used to provide the timestamps of the attribute TimeStampAcquisition of the associated DynamicDrillingSignal.

A SynchronizationGroup is a direct subclass of DWISNoun that allows to define the strata of synchronizations. It has two attributes:

• SynchronizationDelay: A decimal value in seconds that characterizes the delay introduced by the SynchronizationGroup.

• SamplingRate: A decimal value that indicates the frequency by which the SynchronizationGroup relates to the upper stratum.

The verb HasReferenceClock allows linking a SynchronizationGroup with a reference Clock and the verb IsSynchronizedBy allows a Clock to indicate that it is synchronized by a SynchronizationGroup. The verb IsSynchronizationGroupInput is a reflexive relation between the strata of SynchronizationGroup (see Fig. A-1 ).

The Noun Telemetry (a direct subclass of DWISNoun) qualifies the collection of DrillingDataPoint and their transmission to a receiving equipment. It has one attribute:

• AverageDelayByRepeater: A positive decimal value in seconds that informs about the average delay introduced by the repeater on the transmission of information.

There are two main subclasses of Telemetry:

• TopSideTelemetry: This noun is reserved for fixed-length telemetry solutions. It has one attribute:

  • NumberOfRepeaters: A positive integer that informs about the number of repeaters along the transmission line between the source and the receiver of information.

• DownHoleTelemetry: This noun is used for variable-length telemetry systems. It has one attribute:

  • DistanceBetweenRepeaters: A positive decimal value in meters that describes the average distance between repeaters along the transmission line.

The DownHoleTelemetry noun has several specializations that are used to distinguish the transmission method (see Fig. A-2 ):

• MudPulseTelemetry: This noun is used when the transmission of information is made using pressure variations of the drilling fluid transported inside the drillstring.

• AcousticTelemetry: This noun is used to characterize a transmission of information using strain waves along the drillstem.

• ElectroMagneticTelemetry: This Noun characterizes transmission methods based on electromagnetic waves propagating through the formations.

• WiredPipeTelemetry: This noun defines that the transmission is made using wires along the drillstring. It has at least three subclasses:

  • InductionWiredTelemetry: This noun is used when the coupling between pipes es electrical induction.

  • ElectroMagneticWiredTelemetry: This noun is reserved for describing that the coupling between pipes is made using electromagnetic waves between two antennas.

  • GalvanicWiredTelemetry: This noun describes that the coupling between pipes is purely galvanic.

The verb IsTransmittedBy is used to associate a DrillingDataPoint with a Telemetry solution.

The noun DrillingDataFlow inherits from DWISNoun. Its role is to define the data flow by which drilling signals are produced, transferred, and processed. It is specialized through several subclasses (see Fig. A-3 ):

• MeasurementDevice: This noun is reserved to describe a DrillingDataPoint is associated with a measurement device used in the drilling data flow. The verb IsMeasuredBy relates a DrillingDataPoint with a MeasurementDevice.

• UserInterface: This noun is used to tell that a DrillingDataPoint is received from a user interface. The relation is defined using the verb IsReceivedFrom.

• ComputationUnit: This noun characterizes that the DrillingDataPoint is either an input (using the verb IsComputationInput) or an output (using the verb IsComputationOutput) of a computation unit.

• TransmissionLine: This noun informs that a DrillingDataPoint is either an input (using the verb IsTransmissionInput) or an output (using the verb IsTransmissionOutput) of transmission line.

• Controller: This noun is used to define whether a DrillingDataPoint is a set-point (using the verb IsSetPointFor), a manipulated variable (using the verb IsManipulatedVariableFor), or a controlled variable (using the verb IsControlledVariableFor) of a controller.

As discussed with Eqs. 1 and 2, some real-time values are derived from others. Also, it has been mentioned that some real-time values are aggregated together, buffered, and transmitted in packets. The purpose of the noun Transformation is to characterize such operations. It is a direct subclass of DWISNoun and it has two subclasses (see Fig. A-4 ):

• DirectTransformation: Such a noun is reserved for transformation that is time independent. This noun has two subclasses:

  • Aggregation: This noun is used when several DrillingDataPoint individuals having different PhysicalQuantity are grouped together. For example, all the downhole measurements may be assembled in one Aggregation, a packet, which is transmitted using a downhole telemetry solution.

  • ChangePhysicalQuantity: This noun is reserved to describe that a DrillingDataPoint of a certain PhysicalQuantity is transformed into another PhysicalQuantity. This is typically what is done with actual measurements, as their original value is often related to an electrical current quantity and the value is transformed to another physical quantity using a more or less complex conversion (e.g., the electrical potential generated by a piezo sensor is converted to pressure).

• TimeBasedTransformation: This is a noun that is used to describe transformations that depend on time. It has four subclasses:

  • Derivation: A noun that describes the derivation of some DrillingDataPoint values. It has the following attributes:

    • DerivativeOrder: A positive integer value that represents the order of the derivative.

    • DerivativeType: An enumeration that can take the values Central, Forward, and Backward, therefore indicating whether a central difference, forward difference, or backward difference, respectively, is used to calculate the derivative.

  • Integration: A noun used to describe that a DrillingDataPoint is the result of the integration of another DrillingDataPoint. It has two attributes:

    • InitialValue: A decimal value representing the lowest bound of the integral.

    • InitialTimeStamp: A date-time value indicating the UTC time for the lowest bound of the integral.

  • Resampling: This noun describes that the DrillingDataPoint is resampled from a series of values. It has the following attributes:

    • ResamplingOrder: A strictly positive integer value that indicates the number of values used for the resampling, with 1 meaning that the value is copied, 2 corresponding to a linear interpolation, 3 for a quadratic interpolation, and so on.

    • ResamplingType: An enumeration that can take the values Central, Forward, and Backward to indicate whether the resampled value is taken, respectively, in the middle of the interval, after the last value of the interval, or before the first value of the interval.

    • ResamplingTimeWindow: A timespan value that tells the maximum duration of the window used for resampling.

  • Buffering: A noun used to describe a buffer of DrillingDataPoint. The values in the buffer are ordered from the oldest to the most recent. It has one attribute:

    • MaxNumberOfSamples: A positive integer that informs the maximum number of samples in the buffer.

  • TimeEstimationAtSource: A noun used to describe a transformation that estimates the time at source based on the acquisition timestamp (i.e., it fills the TimeStampAtSource attribute when it is undefined).

There are two verbs to link a DrillingDataPoint with a Transformation: IsTransformationInput and IsTransformationOutput.

This paper (SPE 208732) was accepted for presentation at the IADC/SPE International Drilling Conference and Exhibition, Galveston, Texas, USA, 8–10 March 2022, and revised for publication. Original manuscript received for review 9 January 2023. Revised manuscript received for review 12 May 2023. Paper peer approved 16 May 2023.