Re: [foxboro] AIM* questions

Corey.

RE:=20
3) How does AIM* present alarm history data to the AHD on the system?
Does=20
it still generate the almhist file, or does it use some other mechanism?


What I/A version are you using? If you are at pre-8.0, the almhist file
still exists and is used. AIM* does not present the alarms on the AHD,
the Alarm Manager does this by reading the almhist file. AIM* writes the
file however. If you are at 8.0 or later, the Alarm Manager reads the
alarms from the AIM* database via the AIM*API. AIM* still writes the
almhist file however.

Kathy

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Corey R Clingo
Sent: Monday, October 23, 2006 3:51 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] AIM* questions


Hi all-knowing list,


I am investigating a migration to the AIM* historian from legacy.
Legacy=20
works fine, and I normally would not change anything, but we are
averaging=20
about one new "initiative" a month that requires some sort of data=20
collection from the DCS, some of it at relatively high frequencies, and
of=20
varying types (point values as well as alarm and OAJ events).


My primary goal in all this is to establish a "buffer" box that can
supply=20
data to any external application(s) that will tolerate changes in those=20
applications' collection characteristics without increasing system=20
loading.  I currently am running two Solaris AWs, each with legacy=20
historians; they were redundant at one time but we exceeded the
4000-point=20
limit and had to split them.  I am envisioning something like the=20
following:


|------------|        |-----------|
|     AW     |        |     AW    |
| with hist. |        | with hist.|
|  (box 1)   |        |  (box 2)  |
|------------|        |-----------|
       |                     |
       |   (2nd ethernets)   |
       ---------| |-----------
                | |
                | |
            |------------|
            | Windows PC |
            | with hist. |
            | (box 3)    |
            |------------|
                  |
                  |
              External
                apps


Box 1 and Box 2 would be running redundant AIM* instances supplying data

to the system for operator functions, and to Box 3.  Box 3 would collect

from Box 1's and Box 2's historians (not the CPs directly), with the=20
capability to fail over between them (for when we back up an AW) or at=20
least allow manual switching, as well as reconstructing the data from
Box=20
1 and/or Box 2 if Box 3 fails or loses connection totally.  External
apps=20
would collect from Box 3; adding additional external collection would=20
slightly increase Box 1/2/3's loading, but not the CPs', as long as that

collection was asking for data already configured in Box 1's and Box 2's

historians.


So my questions are:


1)  Will AIM* do what I want here?  Can it collect from another instance

of itself?  Can it fail over between collection sources, or at least
allow=20
manual switching?


2) What other "server" interfaces does AIM* offer?  I see legacy and=20
AIM*API and ODBC/OLE DB in the PSS, but what about OPC DA or HDA?


3) How does AIM* present alarm history data to the AHD on the system?
Does=20
it still generate the almhist file, or does it use some other mechanism?



4) Any other ideas or thoughts on architecture or other software to do=20
this?  Any actual experience anyone would like to share (with AIM* or=20
something else)?


Thanks,

Corey Clingo
BASF Corporation



=20
=20
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20

 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: