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






                            IMPORTANT NOTICE !
This E-Mail transmission and any accompanying attachments may contain
confidential information intended only for the use of the individual or
entity named above. Any dissemination, distribution, copying or action taken
in reliance on the contents of this E-Mail by anyone other than the intended
recipient is strictly prohibited and is not intended to, in anyway, waive
privilege or confidentiality. If you have received this E-Mail in error please
immediately delete it and notify sender at the above E-Mail address.

Agrium uses state of the art anti-virus technology on all incoming and
outgoing E-Mail. We encourage and promote the use of safe E-Mail management
practices and recommend you check this, and all other E-Mail and attachments
you receive for the presence of viruses. The sender and Agrium accept no 
liability
for any damage caused by a virus or otherwise by the transmittal of this E-Mail.
                        IMPORTANT NOTICE 



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