Re: [foxboro] AIM* questions

Thanks to everyone for the info so far.  We are/will be running Solaris at 
6.5/7.1, with DM now, and potentially Foxview in the future.  I plan to 
run on-platform instances of AIM* for operator trending and system 
functions, but as Kevin is doing, I would plan to run any 3rd-party 
collector software on the off-platform box co-resident with the AIM* 
instance (to avoid DCOM and other unpleasantness).  To follow up on what 
George says, I have a couple more questions:


1) Can you delete the old data without archiving it?  We generally don't 
need more than a few months' worth on the system historians.


2) Does the "BLAN" Win2K instance you mention always collect from the AW 
_historians_, rather than directly from the CPs?  Obviously it does in a 
failure scenario, as you state that it can backfill missing data.  How 
exactly does it work (AIM*API history calls or some other mechanism)?  Can 
you set it up to collect the same tags from more than one external AIM* 
instance, to provide failover/backup capability in the event one of the 
AWs is not operational (as opposed to the off-platform server failing)?


Apologies in advance if I can find this stuff by reading the manual.  I 
will download it and look it over when I get time.  At this point I just 
want to know if I should pursue AIM* any further.  From what I am reading, 
it sounds like it might do what I want.


Corey Clingo
BASF Corporation






"George Bocancea" <GBocance@xxxxxxxxxx> 
Sent by: foxboro-bounce@xxxxxxxxxxxxx
10/25/2006 09:07 AM
Please respond to
foxboro@xxxxxxxxxxxxx


To
<foxboro@xxxxxxxxxxxxx>
cc

Subject
Re: [foxboro] AIM* questions






Corey,

AIM* can do what you are looking for.
We are using 4 AIM* historians on 4 different AWs (3 Solaris and 1 XP) on 
the CLAN. AIM does not make a circular file like the legacy. You have to 
properly setup archiving on each of these, as they fill up your /opt 
partition quite fast. We have setup the archiving/deleting on these at 
about 180 day, depending on AW51 box style. But these four AIM* are used 
by the operators for trending and for the AHD. No more legacy needed.

On the BLAN we are using a Win2000 Server with another AIM* license 
collecting through the 4 AWs instances on the 2nd ethernet. There is no 
failure between this and the collectors. We can take the server down and 
when it comes up it just transfer the missing data from the other 4 AIMs. 
The server is off-platform and used for long term data retention (80 GB 
hard drive can hold up to 4-5 years of about 4000 points history). On this 
server we are using the Report Package that comes with a scheduler (Opalis 
Robot), and run daily, weekly and monthly production reports that email 
automatically to accountants for inventories, billing, management. Also we 
are using WISE software (~Web-enabled Info System for Executives), where 
we are posting these reports, and which has a Chart Tool that BLAN desktop 
users can use to access AIM* data (static trending or excel-friendly data 
sheets). We wish AIM would have some statistical analysis tool and an 
interface for desktop users, but I've hear
d IPS is releasing another historian under the "ConFusion" platform.

Hope this helps with your quest.
George Bocancea
Calgary - Canada
>>> corey.clingo@xxxxxxxx 10/23/2006 1:50 PM >>>

Hi all-knowing list,


I am investigating a migration to the AIM* historian from legacy.  Legacy
works fine, and I normally would not change anything, but we are averaging
about one new "initiative" a month that requires some sort of data
collection from the DCS, some of it at relatively high frequencies, and of
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
data to any external application(s) that will tolerate changes in those
applications' collection characteristics without increasing system
loading.  I currently am running two Solaris AWs, each with legacy
historians; they were redundant at one time but we exceeded the 4000-point
limit and had to split them.  I am envisioning something like the
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
capability to fail over between them (for when we back up an AW) or at
least allow manual switching, as well as reconstructing the data from Box
1 and/or Box 2 if Box 3 fails or loses connection totally.  External apps
would collect from Box 3; adding additional external collection would
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
manual switching?


2) What other "server" interfaces does AIM* offer?  I see legacy and
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
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
this?  Any actual experience anyone would like to share (with AIM* or
something else)?


Thanks,

Corey Clingo
BASF Corporation



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