PI System Time Synchronization

Version 1.0

January, 2015

OSIsoft, LLC
777 Davis St., Suite 250
San Leandro, CA 94577 USA
Tel: (01) 510-297-5800
Fax: (01) 510-357-8136
Web: http://www.osisoft.com

OSIsoft Australia • Perth, Australia

OSIsoft Europe GmbH • Frankfurt, Germany
OSIsoft Asia Pte Ltd. • Singapore
OSIsoft Canada ULC • Montreal & Calgary, Canada
OSIsoft, LLC Representative Office • Shanghai, People’s Republic of China
OSIsoft Japan KK • Tokyo, Japan
OSIsoft Mexico S. De R.L. De C.V. • Mexico City, Mexico
OSIsoft do Brasil Sistemas Ltda. • Sao Paulo, Brazil
OSIsoft France EURL • Paris, France
 Copyright: © 1992-2014 OSIsoft, LLC. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical,
photocopying, recording, or otherwise, without the prior written permission of OSIsoft, LLC.

OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, PI Asset Framework (PI AF), IT
Monitor, MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI Data Services, PI Manual Logger, PI
ProfileView, PI WebParts, ProTRAQ, RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of
OSIsoft, LLC. All other trademarks or trade names used herein are the property of their respective owners.

U.S. GOVERNMENT RIGHTS

Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the OSIsoft, LLC license agreement and as
provided in DFARS 227.7202, DFARS 252.227-7013, FAR 12.212, FAR 52.227, as applicable. OSIsoft, LLC.
Version:

OSIsoft, LLC.
 Version 1.3, December 2014
Federated PI System Management Introduction

Table of Content
Introduction ............................................................................................................................... 2
References ............................................................................................................................................. 3
Critical Time Components ........................................................................................................ 4
Time Signal Architecture .......................................................................................................... 5
Time Source Design Criteria .................................................................................................................. 5
Architectural Considerations ................................................................................................................... 5
Platform-Specific Time Configuration ..................................................................................................... 7
PI System Time Configuration ................................................................................................. 8
PI Data Archive ....................................................................................................................................... 8
PI Interfaces............................................................................................................................................ 8

1
 Version 1.3, December 2014
Federated PI System Management Introduction

Introduction
Data synchronization is one of the biggest challenges in the real-time data collection business. Proper time
stamping of the process data is crucial to allow the process engineer and other real time data consumers to
correlate data coming from different data sources. Only if the correlation is made under the same
synchronization base will the engineers be able to understand the current sequence of process events.
Proper time synchronization is critical to ensure the following:
 Correlation of events between control systems and PI system data streams for event and process
analyses
 Elimination of data loss due to invalid (future) timestamps
 Reduced risk of OSIsoft NOC monitoring failure due to time offset drift
 Efficient troubleshooting process performed by either customers, OSIsoft NOC engineers or OSIsoft
Technical Support engineers
 Accuracy of enterprise level KPI calculations utilizing data collected from multiple systems

The purpose of this document is to provide architectural design and PI System configuration
recommendations which impact time services and synchronization.

2
 Version 1.3, December 2014
Federated PI System Management Introduction

References
Reference Source
NTP.org list of public time servers External Data Source
[LINK TO WEB SITE]
Microsoft article on how to configure the W32Time service Microsoft Article
[LINK TO ARTICLE]
Microsoft article describing how the W32Time service works Microsoft Article
[LINK TO ARTICLE]
VMWare time configuration best practices External Data Source
[LINK TO DOCUMENT]
Hyper-V time configuration best practices External Data Source
[LINK TO DOCUMENT]
NTP.org download site for UNIX NTP daemon External Data Source
[LINK TO WEB SITE]
Hyper-V time configuration best practices External Data Source
[LINK TO DOCUMENT]
NTP.org download site for UNIX NTP daemon External Data Source
[LINK TO WEB SITE]
Open source UNIX time accuracy tool External Data Source
[LINK TO WEB SITE]
OSIsoft article about Future Data OSIsoft Article
[LINK TO ARTICLE]
OSIsoft PI Interface Configuration Utility user manual OSIsoft Article
[LINK TO MANUAL]
OSIsoft PI Universal Interface user manual OSIsoft Article
[LINK TO MANUAL]

3
 Version 1.3, December 2014
Federated PI System Management Critical Time Components

Critical Time Components

There are three key attributes of time which impact the performance of the PI System: accuracy, stability
and availability.

Absolute time accuracy represents the time offset from the expected time. It is important for correlating the
real time data with external events that were not collected by the same system. An example of wind power
generation (collected by the wind farm operator) with the load on the grid (captured by the grid load
balancing authority): If both the wind power operator and load balancing authority had their systems
synchronized with an accurate time source, the data will obviously have a good time correlation. This would
allow them to perform more accurate ramp event analysis in case they need to find the correlation between
these sets of data. The required accuracy level will vary. For ramp event analysis, ±1 minute is more than
enough accuracy. For turbine event analysis, a few seconds of time accuracy is expected. For COMTRADE1
data comparison and sequence of events analysis, an accuracy in the order of milliseconds may be required.

The stability associated with the clock oscillator hardware characteristics also plays an important role in the
correct time stamping of data. It monitors the rate of clock frequency drift in a determined amount of time
and can be divided into short term and long term stability. Short term clock stability will not affect the PI
system, as the data scan rates are very low if compared to the frequency offset caused by the stability issues.
However, the long term clock stability can cause an accumulation of the clock frequency drift, affecting
absolute time accuracy.

The relationship between accuracy and stability is illustrated in Figure 1:

Where:
fo = ideal clock frequency
f = observed clock frequency

Figure 1 - Relationship between accuracy and stability

Even the most accurate and stable time signal available won’t be of use if your servers can’t reach it.
Having the proper network architecture in place is required to ensure the time signal is consistently
available.

1 Common format for Transient Data Exchange for power systems

4
 Version 1.3, December 2014
Federated PI System Management Time Signal Architecture

Time Signal Architecture

The information provided in this portion of the document describes the components making up a time
signal solution. The questions and recommendations presented should assist you in designing a time
solution which best fits in your environment.

Time Source Design Criteria

To design the proper architecture for your time-related needs, answers to the following questions and
design criteria need to be gathered:
1. Accuracy – Do you need data values refreshed faster than once every 1-2 seconds?
2. Stability – Need to decide if preventing clock drifting and the resulting large correction
adjustments is a requirement
3. Synchronization – Identify the equipment (i.e. servers, workstations, firewalls, switches)
which require a managed time solution and/or synchronized times
4. Availability – Map the locations of your time-sensitive equipment in a network diagram so
you can identify potential communication failure points which would impact the availability of
the time signal
The details gathered above will be used to step through the following time system architecture decision
points and build the most appropriate solution for your environment.

Architectural Considerations
The information provided in this section of the document covers some basic architectural details which
need to be considered when designing the most appropriate solution for your environment.
Master Time Signal Source
A master time source provides the timestamp used by all other devices and applications in a given
environment. On the Microsoft Windows platform, these are three master time signal options:
1. A given server on your network has the “W32Time” service configured to act as a Network Time
Protocol (NTP) provider. The source of this time signal would be the CMOS clock inside the
server. There are two main design considerations associated with this option:
a. The Microsoft Windows time service is using the server’s internal clock as its source.
This signal is not considered stable because the time will drift as the CMOS battery
degrades
b. The Microsoft Windows time service’s highest time resolution is 1-2 seconds. For
environments needing higher accuracy, another option is required
2. A certified NTP server located on the Internet is selected to provide the master time signal. There
is a web site named www.ntp.org that lists available servers; the following URL will take you to
their site so you can search for servers near you:
http://support.ntp.org/bin/view/Servers/NTPPoolServers. There are four main design
considerations associated with this option:
a. There is no cost associated with these public servers
b. You are relying upon an unknown provider and the health of the Internet to ensure the
signal is both accurate and consistent

5
 Version 1.3, December 2014
Federated PI System Management Time Signal Architecture

c. Because these signals are coming from the Internet, there is a chance they could be
manipulated
d. You need to open access in your firewalls to these public servers
3. A GPS-based hardware time server is installed on your network to provide a NTP signal using
dedicated client/server software or by configuring the list of NTP servers in the time service of a
given piece of equipment. The following design considerations are associated with this option:
a. These hardware-based solutions provide the greatest accuracy
b. As long as you have a connection to the GPS satellite, these signals are very stable and
consistent
c. Because the signal is originating in your environment, there are no Internet-based security
or performance concerns
d. There is a cost associated with purchasing these solutions
Based on the considerations described above, OSIsoft recommends that their customers implement a
hardware-based master time source. Every server which is running PI software or software which
interfaces with PI should be configured to use this time signal. The below diagram shows the components
associated with such a solution.

GPS Satellite

Domain
Controller

Internal
NTP Server

Critical Computer Critical Computer Network

Client Computers
Nodes with Nodes with Time Sync Devices
W32Time Service Client Software

Figure 2 - Clock synchronization architecture based on GPS and sync software agent
While there are many GPS-based solutions available on the market, you should look for one using client/
server software if your data needs to be refreshed faster than every 1-2 seconds. If you do not have the
second or sub-second data accuracy need, you can implement a NTP server which the Microsoft Windows
W32Time service connects to using either the Active Directory time functionality or the IP address of the
NTP server.

6
 Version 1.3, December 2014
Federated PI System Management Time Signal Architecture

Primary and Secondary Time Signals

Time signal availability is managed by where you place your time server. For many companies, the master
NTP signal is placed in the corporate data center containing the Microsoft Domain controller. This
solution ensures time synchronization across all network devices, servers and workstations which have
reliable WAN and LAN connections to the Corporate network. While the above scenario meets the needs
for some, the following considerations could require the installation of a second time signal:
1. Remote sites have a slow or unreliable WAN connection – could require a locally-installed NTP
server. For consistency reasons, the local time server solution should be identical to the master
time server
2. Redundant time servers are needed to meet availability requirements – a secondary NTP server
could be installed locally or in a second corporate data center. The best solution depends on the
number of sites needing a redundant solution and reliability of WAN connections between sites

Platform-Specific Time Configuration

The information provided in this section of the document provides some platform-specific information
which impact time settings.
Microsoft Windows
There are three main time-related scenarios for managing time on Microsoft OS machines:
1. A third-party, time synchronization client application is installed. This scenario applies when the
server/workstation requires second or sub-second data values and is using the special software to
communicate with the time signal’s server-side application
2. The server or workstation is part of a Microsoft Active Directory domain. In this case the domain
functionality is providing the correct time values. The only server on the domain which needs to
communicate with the NTP server is the Domain controller
3. The server or workstation belongs to a local workgroup and is using the W32Time service. In this
case, the following Microsoft article provides details on how to manually configure W32Time to
use an external time source: http://support.microsoft.com/kb/816042
For more information on how the W32Time service works, the following Microsoft article provides an
excellent overview: https://technet.microsoft.com/en-us/library/cc773013(v=ws.10).aspx .
Virtual Machines
The main point to remember when running virtual machines on a Microsoft OS host is to disable the
Virtual tool’s time synchronization options and use the W32Tine service or third-party time client
application instead.
Additional information on troubleshooting time on VMWare and Hyper-V virtual machines can be found
on these web sites:
1. VMWare:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&e
xternalId=1318
2. Hyper-V: http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-
in-hyper-v.aspx

7
 Version 1.3, December 2014
Federated PI System Management PI System Time Configuration

UNIX
There are two main points to consider when working in an UNIX environment:
1. Most versions of UNIX install the NTP daemon. If your version of UNIX does not have this
component or if your version is not current, you can download the latest version from the
following web site: http://www.ntp.org/downloads.html
2. There is an open source solution named “Chrony” which will maintain the accuracy of the system
clock on a given computer. The following web site provides more details on this option:
http://chrony.tuxfamily.org/

PI System Time Configuration

All time series data is stored in the PI Data Archive Universal Time Coordinated (UTC) time zone value.
The PI interfaces and clients automatically adjust the values being written to and read from the server
based on how the PI System is configured. The purpose of this section is to describe the PI System
components and configuration which affects or is impacted by the time server.

PI Data Archive
Because the PI Data Archive is where all of the time series data is stored, there are some important time-
related features to understand:
 During the installation of the PI System, you are required to download and install the correct
local time zone file from the OSIsoft Tech Support web site. These time zone specific files
contain the rules used to convert the server’s time zone to the UTC data values stored in the
archive. These files can be found by searching for the product named “localhost.tz” on the
Downloads page of the Tech Support site
 Time stamp values and their impact on PI Data Archive storage

Each Data Archive event consists of the following components: a timestamp, a value and
quality bits if any are set. The timestamp component includes the following properties:
o Uses 1-4 bytes without sub second data and 2-8 bytes with sub second data.
o Only an offset is stored containing the amount of time since the previous event. If you
have a tag with frequent archive events, fewer bytes will be needed for the offset
because the amount of time being measured is smaller. If there is a large amount of
time since the last archived event, and a large offset is needed, it will take more bytes.
 At this time, the concept of “future data” is new and will be released in the next version of the
PI System. The following link will take you to an article on the PI Square web site which
describes how this functionality will work: <Use this link>

PI Interfaces
PI Interfaces are used to populate the PI Data Archive using the customer’s data source of choice. While
each interface is written for a different source provider, the following components are standard across all
OSIsoft interfaces:

8
 Version 1.3, December 2014
Federated PI System Management PI System Time Configuration

1. The PI Software Development Kit (SDK) and the PI Application Programming Interface (API) are
two technologies which perform the data transfer
2. The PI Universal Interface (UniInt) is a software framework for interfaces to the PI Server. UniInt
provides generic functions required by most interfaces. Using the UniInt framework ensures a
standard set of features for OSIsoft interfaces to PI and prevents duplication of effort.
3. The PI Interface Configuration Utility (ICU) is an application used to configure the interface’s
behavior
This section describes how the interfaces impact the data written to the PI Data Archive, reinforces
why time synchronization is so important and shares some general information on time behavior in
interfaces.
 Interfaces can be configured to send one of two date/time stamps to the PI Data Archive: the
current time on the PI Interface server or the date stamp sent from the source system. The PI ICU
manages this configuration option using the “/TS” runtime parameter. More information on this
functionality is found in the user manual of the specific interface being used.
 As mentioned earlier, time synchronization between servers is critical to ensure time stamps are
created and passed through interfaces correctly. To prevent data quality issues, you need to
ensure that the PI Data Archive, PI Interface Node and Source Data servers are all using the same
NTP server. In the event that your PI and source data servers cannot use the same NTP server, the
“/TS” runtime parameter mentioned above should be set to use the time of the PI Interface server
 Scan class are defined within the PI-ICU configuration to control the frequency a given tag is
scanned for a new value. While using faster scan rates will increase the resolution of the values,
you need to ensure the accuracy of your time source will support your desired scan rates.
Additional details on configuring scan rates can be found in these documents:
o Scan class configuration information is provided in the PI-ICU User Manual
o Configuring sub-second scan rates is described in the UniInt Interface User Manual