Now we call the layer of software that
grabs data from a data source in the field
and brings it into the PI Server -- we call that
an interface. And the interface is generally bringing
data, you know, in this direction, bringing the data into
the Pi Server, but it also has the capability in some
cases to bring data from that PI
Interface out to the data source itself. That's an
output. So many of the interfaces support that.
We typically will run this interface
on its own computer, as it's pictured here.
And when we do that, we tend to call that computer
an Interface Node, or sometimes we will call it a Data
Acquisition Node. Actually, if you go back,
historically, we have called them API Nodes,
or we have even called the older VMS Versions
PI Net Nodes. So you might run into those terms
in some of our older documentation. Now, I say
that we typically will run this on a separate computer,
but that's not always necessary. It's not even always a good
idea to do it that way. So, there's different
configurations really depending on your situation. We will go over a few of those as we
go through. And one of the things the interface does
is it can, if it's on a separate Node, the interface
can buffer data temporarily in the event
that the connection to the server is down.
So, if that server is down, we can buffer data locally.
Ends up being a very nice feature. And then, of course,
once the system becomes back on line, we take that
data and we send it back. And that's all automatic.
So, there's a lot of good features like that in
an interface. You can do local buffering. The interface should be
writing its own local Error Logs
you can use for troubleshooting. It should automatically start up,
so every time the computer restarts,
the interface should start. Hopefully, that'll avoid
that, you know, that 3 am phone call that
you might get from Operations if there's been a power
failure, and the interface has to, that Interface Node here
has to restart. Thankfully,
with the Auto Restart you will not get that 3 am phone call.
And then, also, the interface, any good interface
should report by exception. And by
reporting by exception, what I mean is if we are going to
scan a Value, say, once a second,
you know the odds of that Value changing significantly each
and every time you scan it -- you know, in these PLC's
you are looking at temperatures, pressures,
voltages, things like that. Well, maybe the voltage is going to change
several times in, within the course of a second,
but all the other things, they tend not to change that quickly.
So, we typically will want an interface to
report only by exception. So, you know, we generate
a tremendous amount of data over here, most of which can be considered
noise, and we want to bring only those Values
that real -- into the interface and, and then
from the interface into the PI Server. We only want to bring those
Values that are significant, and, of course, you are the one that
gets to determine what's significant. So you can ignore
as much or as little as the data that you might
consider noise as you want to. In the videos
to come, we are going to be installing a couple of different interfaces,
and we are going to discuss, you know, how do we install, how do we
configure those interfaces. The first one we are going to configure is something
called the Ping Interface. We are going to start with that 'cause it's the
simpler of the two, and this data you see coming in, those are
actually measuring the ping rate. That's a ping
rate that's being measured in the,
the millisecond it takes to respond one
computer to another. And that's what ping measures.
We suggest using the Ping Interface
which ships with every PI Server by the way. We
suggest using the Ping Interface to take a look at your other Data
Acquisition Nodes, any other major equipment that
you have got in your system -- switches, routers, stuff like that.
Any Internal Application Servers, external websites
that you rely on -- you know, all those are things
that it would be very nice to be able to bring all
that data in so that you can see -- well, like you can see
in this overall trend here. As you can see, this trend is
showing me that the ping rate is increasing
slowly. That's an indication that there's some
problem. The, the latency is increasing over time, so there
must be some kind of a bottleneck in the system.
Anyway, that's not terribly important right now. The point
of this is that we are going to be configuring that interface, and we are going to start
with a fairly simple interface, that Ping Interface.
The other interface we are going to install is called the
OPC Interface. We like to install that one
because it's the single most common interface out there.
It's very likely that you are, you know, if you are like most of our
customers, you probably have got an OPC Interface somewhere in your system.
Even if you do not have this particular OPC
Interface, whatever interface you have is going to be very
similar to the OPC Interface. They are all built off of a
standard that we call Uni Int for Universal Interface. So,
we will do the OPC Interface, and we are going to be using that
to gather data from an OPC Simulator that we will
encourage you to put on your own machine so you can try that yourself.
Now you have a couple of different ways that you can
architect these interfaces. For example,
you can put the data source, the
interface, and the layer of software,
our SDK, API and Buffering Service.
You could put all of those on the same computer. That's what we mean
with this solid line here. This solid line
indicates that everything's on one computer. So that would be
one computer. This would all be another computer. This would be
a third computer here. So, anyway,
imagine that we have put all of this on one computer.
Option A here indicates that
everything that we need in order to
gather that data and bring it to the PI Server is
basically on one machine. So the data source, for example,
would be the piece of equipment that's actually generating the data --
PLC's or Control System or
basically anything that's generating real-time data.
Now you can install the interface on that same computer.
You can then install our buffering
service. That's the one that will buffer data locally
if the connection to the server breaks for some reason.
So that's all on one machine, and in some cases that's
the best architecture. By far, I think the most common
architecture, and the most robust architecture,
is not to do it that way though, but
instead to spread the computer on different machines
or the interface on and the, the data collection on
different machines. So it's fairly typical to have the
data source on its own dedicated machine, and that
may be a Windows machine, a Unix machine, or some proprietary
hardware from a PLC manufacturer or a DCS
manufacturer of some type. And,
connected to that, and over regular network cables, you
would get a computer -- this would be a Data Collection
Node -- in which we have installed the PI Interface layer.
That's the software, again, that does the collection.
And then, in addition, we will install the SDK
or API to do the buffering
that will allow us to buffer that data locally.
So, that would be kind of a traditional
Data Collection Node. And, of course, it sends its data on to the PI
Server. Now, lastly, if your data source
is on a separate machine, you can put the
interface and the buffering layer -- you can put all
of that on the same machine that's running your PI
Server. And, in that case, if you did
have to bring this down for, let's say to do an upgrade,
then the data will just, will just buffer locally on the
same computer that's running the PI Server. So that's an option.
As I said, for all of these options what you really want to do
is choose the one that's right for you. You know, talk it over with your
salesperson, or whoever's doing the install. Most typically,
though, what we see is people choose this option right here.
And this would be, as I mentioned earlier, the traditional
Data Collection Node, the Interface Node.
Interface and the buffering layer all on
a separate computer.