Re: [foxboro] AIM* questions

Corey,

I've got a large AIM* license (50,000 points) split between 3 off platform
historians on servers running Win2K Server.  We have remote collectors on 7 of
our AWs.

We run OPC DA and HDA servers on the three AIM* servers.  We found it was far
more efficient than running OPC servers on a separate workstation.  We've used
the ODBC and OLEDB features of AIM*.  When we put the system in, around AIM*
3.2, OPC HDA was buggy and ODBC and OLEDB were next to useless for our purposes.
 We're fairly happy with OPC HDA as of version 3.3 + QF1008205.  I believe the
last of the CARs we wrote agains AIM* in early 2004 are being addressed by the
recently released AIM* 3.2.4, although we haven't tested to confirm.  Some of
these CARs were for problems with OPC HDA, OLEDB and ODBC.  The rest were for
features we used in the Legacy Historian that were lost or broken going to AIM*.

If you use off-platform AIM*, one of the big limitations in my mind is having
only one legacy server per off-platform box.  In one plant area we have 4 remote
collectors for a historian, which works well, but we can have only one legacy
server (which provides trend information to all the AWs and WPs), so if the box
with the legacy server is down for a backup or upgrade, all trending is lost.

Another issue we've struggled with is getting the AHD displays to work on the
WPs after shifting to off-platform AIM*.  

System definition doesn't really do a good job when off-platform instances are
configured.  You have to pick one AW to "own" foxhistory in sysdef so you can
direct system monitor messages to a historian.  The /etc/histln histlns and
histlocs files are written during some committals/updates/QFs and by the AIM*
historian itself, unfortunately they are often written incorrectly for our
off-platform instance.

We've also had periodic problems with the remote collectors and the AIM*
instance somehow becoming un-synched.  We usually kill all historian processes
on the AWs and reboot the AIM* server to fix, but it is a pita.  Usually this
happens because an AW has rebooted for some reason.

Our current AIM* version (3.2.3) doesn't have a search function in the database,
so if you want to edit a single tag in a 20,000 tag historian, scrolling through
20,000 entries until you find your tag is awkward.  I usually dump the .inp file
and get the index number of the tag I want, but that only gets me to the right
neighborhood, as index numbers in the .inp file only match those in the
historian database until a tag is deleted.

In spite of the above gripes, the large AIM* instances are a big step forward
from our multitude of legacy historians.  

Our configuration is enough different than yours that I can't answer most of
your questions, but feel free to contact me for more feedback on our
off-platform AIM* installation if you want.

Regards,

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


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