Re: [foxboro] AIM* questions

Kathy,

Is that so?  My systems are at 6.5.1 and 6.5.2.  When the historian is available
AHD works normally.  When the historian is not available, AHD puts up a warning
screen saying it is recovering alarms from the almhist file.  This always
implied to me that the historian was serving alarms to AHD.

Regards,

Kevin FitzGerrell
Carter Holt Harvey, Ltd.
+64 27 460 9994

Quoting "Grace, Kathy" <kathy.grace@xxxxxxxxxxxxxxxx>:

> 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
>  
>  

 
 
_______________________________________________________________________
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: