An interface is software
that allows communication between the PI Server and a data source.
So typically what that means
is the data source is the origin of the data. And
traveling in this direction, we bring that data from the
data source into the PI Server. With these data sources,
we tend to talk a lot about
control systems like Siemens or Honeywell.
But of course there is a whole variety
of data sources from IP resources
to phone systems. We even looked at
telemetry from Nascar. There are all types of data sources out there.
And PI System is a general
tool that can be used with all of them. However historically
we have started in the manufacturing world.
So these data sources are the origin
of all of the things that we are interested in typically through the interface.
The data source is going to be read
from the interface application itself.
And that interface establishes a connection with the
data source. And we have interface specialists
who have written interfaces to 100s of different
data sources in the field.
So it's that interface that establishes the connection and
starts retrieving data. Now that interface
generally is going to send the data directly to the PI Server.
Except we do have another
layer called Buffering that is an option, and a very
highly recommended option. Buffering
is something that will more or less
get itself in between the interface and the PI Server.
So when the interface tries to send
data to the PI Server, with Buffering it typically
starts before the interface is going to accept it and
then forward that along to the PI Server. The beauty
of that is if for any reason the
PI Server is not available
then this interface will automatically do buffering using that
buffering sub-system and will take that data and store it
locally. Now as we see here
in this drawing, the interface does not have
to run on this Data Acquisition Node and it's labeled optional.
You can run an interface on the
PI Server itself. Typically we do not
recommend that because this is a PI Server
that may have 100s of users. And that's not the best
platform to use for high speed data collection.
When people log out at the
end of a long day... It's
4:30PM and everyone is logging out of the system, that's probably
not the best time to try to be retrieving data at
high speed. Or let's say that somebody sends an
email out that points out some anomaly
in your history and everybody swarms
over to the ProcessBook and DataLink and starts looking at that data.
When you have got a lot of user
interactions as you do on the server, that's not the time
to be trying to retrieve data at high speed. So
there are some good reasons that we suggest using these
Data Acquisition Nodes. Ultimately the decision
on whether you have one of these Data Acquisition Nodes or not,
that really depends on several things-- your network architecture,
the bandwidth available to you, which interfaces are
being used, and the types of data sources that are being monitored.
So it's not always
the right thing to have a Data Acquisition
Node. But that's typically where we suggest people start.
In fact, sometimes when people are interested in doing
redundant servers, if they do not have a Data Acquisition
Node first, we will tell them we will just save your
money on the redundant hardware first. Let's get a
Data Acquisition Node because those have been so successful over the years.
We really suggest that as a good starting point.
So again, to summarize, the interface is collecting
data from the data source.
It is typically located on a different computer,
a Data Acquisition Node. But it can in fact run on the PI
Server although we typically do not recommend that.