Re: [foxboro] IACC Projects (was: IACC Projects)
- From: tom.vandewater@xxxxxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Wed, 2 Feb 2005 13:53:32 -0500
Marcel,
Thanks for sharing your experiences using IACC. The ball is finally
rolling and users are able to get a better feel of what it involves. This
is what should've happened last August. As Duc, and now Ken Haywood, both
pointed out, this is an unique opportunity for Foxboro and users to give and
receive information about Fox IA products and I have positive proof that
many ears are listening to what goes on in discussion on this list. But
only a few Invensys employees have been actively participating with
feedback.
We all know that what is said on this list is never an official
company stance. It just relays experiences and opinions that may or may not
be helpful to the participants. In the case of IACC, it appears that the
majority of experience using it lies within the Invensys ranks. Users often
want someone else to do all of the Beta testing and bug fixing before they
make a decision to use a new application. They want to be sure that the
product is ready for "prime time". Past experiences tell them that just
because a product is offered for sale doesn't mean it is ready to be useful
or even currently available!
Discussing IACC openly in this forum may well be the best marketing
tool Foxboro has.
I currently have another question about it.
When using IACC in a plant environment I have heard warnings about making
sure that the IACC database is in sync with the CP, (much like the ICC
problem when the workfile gets corrupted or isn't in sync). Does IACC use
the same "upload" capability to insure that the database is in sync with
what is running in the CP?
i.e. If a CP is downloaded using the database of IACC and then alarm
settings, tuning, or changing of other display settable parameters occurs,
how does the IACC database get updated with those changes?
Thanks for any insight.
Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corporation
Carrollton, KY USA
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Sieling, Marcel
Sent: Wednesday, February 02, 2005 8:26 AM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: [foxboro] IACC Projects (was: IACC Projects)
Alex and all,
I supported the Invensys team on the Degussa project which Eric Konings
already mentioned here on the list.
Let me add some comments on Greg's questions:
> 1. How many folks are using IACC on a regular basis at this
> point? Lots, many internal IPS employees use it every day.
I don't have the company overview but in our german office we have several
projects using it today without any big issues. E.g. currently we are
transferring the BASF toolkit to IACC and it seems to work fine as far as I
can tell.
> 2. Do you consider it robust?
> I do. It has been heavily tested and is well documented. It
> is our preferred configuration tool.
Perfectly agree, as long as the user uses it the way it is intended to be
used.
> 3. Is it capable of handling a project of around 3000-4000
> I/O points? We are doing jobs today with over 90,000 blocks.
> I'm certain that IACC can handle a project this size.
The officially communicated limit of the current avaibable IACC Version 2.0
is (as far as I'm informed) 16.000 Objects in the Object Store Database
which is around 3-4 full CP60s. 90.000 blocks seems to be far beyond this
size. I have no personal experience with this size of database in IACC, but
with three CPs there are certain operations (bulk generate around 20 min,
deletion of all CSDs 30 min), which take already pretty long to perform and
therefore impact engineering efficiency. In the current project the size
limit of the IACC database and the single user restriction (which both have
an unintentional and temporary character) introduce the biggest amounts of
additional and unproductive work due to database syncronization between the
different IACCs used and due to the exporting and importing of commonly used
objects like Faceplates, Strategy Templates (the former FoxCAE Typicals)
etc. from the master IACC to the others.
Both issues will be resolved in IACC 3.0 and work is well underway to
resolve this, although release dates are not officially communicated, so
don't ask me for these. ;-)
> 4. How easy (or difficult) is it to backup/restore your IACC
> database? I can't comment specifically because I'm not a user myself.
very easy, there are simple and well working tools implemented to perform
this tasks. The importer of IACC export files analyzes the contents and
structure of the imported data and allows a dedicated import of single
objects, trees or groups of objects or of the whole data, all can be defined
very nicely in an import wizard. During import you can choose, if imported
data overwrites existing data with the same name or is placed as a duplicate
besides it causing a name conflict which has to be resolved by the user
manually later to achieve error-free validating.
Import and Export is one of the power features of IACC. (And thank god for
this as we need it heavily to synchronize different IACCs used in one
project). ;-)
> 5. Does IACC have bulk configuration import capability of
> either Excel- or text-formatted information? Yes. IACC has
> bulk import capability. I'm not an expert, but the details
> are in the manual. The manual is B0400BP.
Bulk import is a powerful and very flexible feature of IACC, the taglist
import wizard is really very nice, but IACC requires all data for a given
CSD to be in one taglist. Having several different lists from the customer
containing data for the same loops (e.g. a I/O Taglist and a seperate Alarm
Limit List and a seperate Interlocking List) requires to merge them together
in a meaningful manner to one master IACC Taglist. We solved this in an
Access application implemented in the workflow between the customer's lists
and the IACC bulk generation. The advantage is, that in this merging Access
program consitency checks can be implemented to ensure correctness of
customer data (e.g. to detect double assignment to I/O channels, or wrong
assignments like binary signals on analogue channels or inputs assigned to
output channels etc.). This has worked fine so far, but you need an Access
expert to achieve this functionality and comfort. All projects I know
executed with IACC work with this approach.
But there is another point to be taken care of:
When performing a bulk generation from the taglist, all concerned CSDs
(loops) are deleted first (!) and then created completely from scratch using
the information stored in the taglist and in the CST (typicals). This is
important, as manual changes are lost after this bulk generation. There are
only two ways to overcome this situation currently: Either you decide to not
bulk generate anymore after a certain milestone and have no problems after
this, but you never can bulk import new data from the customer from then on.
Or you import each and every speciality in the loops from the Taglist. This
implies, that for each speciality a new Tag propagation, a new Taglist field
and new value propagation in the CST has to be implemented. Advantage of
this: At any time you can regenerate the whole database from the Taglist
without loosing any single bit and you have the full control over what is
created from the taglist. Disadvantage: Propagation rules become lengthy and
complex and are probably difficult to maintain.
We chose for the second way and we would do it again, so think some
colleagues of mine in other Invensys offices also using IACC.
> 6. Does IACC replace System Definition, or any other
> configurators, or just ICC? IACC can be used in place of
> SysDef as well as ICC.
Correct. I would go further: we had problems with systems for I/A 8.0
configured with SysDef 2.5 and then exported and imported to IACC, the
import of the standard SysDef Export data into IACC failed for some strange
reason, although it should work and there is no hint in the release notes.
The only way to come out of this issue was to completely rebuild the whole
system with IACC.
So my recommendation is, that all systems with I/A 8.0 and higher should be
defined using IACC rather than SysDef although it looks like as if it should
work (all 8.0 hardware is supported in SysDef 2.5). Don't ask me for
possible reasons, these are facts we have to face. ;-)
> 7. Does a system configured with IACC still have a CSA database? Yes.
> CSA is used - principle function - to ensure uniqueness of
> top-level OM names (compounds). This does not change based on
> the configuration tool.
Correct. IACC is just another means of configuring the good old I/A stuff,
which is pretty much like we all know it. If you know I/A, you get familiar
with IACC very soon. We still have vrtx in the CPs, CSA and OM in the
system, you feel like home very soon, I promise.
> 8. Any other general opinions/comments?
> You need to be at V6.4 or later. Certain model A stations are
> not currently supported.
I'd like to add the following points:
* obey the communicated limits of IACC
* remember only one user per database at a given time
* calculate additional effort when using several IACCs to syncronize them
* Don't use IACC 1.x any more. Just don't argue, simply don't do it.
Hope that helps.
Best regards -
Marcel Sieling
Systems Technologies
Invensys Systems GmbH
Emanuel-Leutze-Str. 11
40547 Duesseldorf
Germany
Tel.: +49-211-5966-302
Fax: +49-163-99-5966302
Mobile: +49-163-5966302
Email: mailto:marcel.sieling@xxxxxxxxxxxxxxxx
Homepage: http://www.foxboro-deutschland.de
> -----Ursprüngliche Nachricht-----
> Von: foxboro-bounce@xxxxxxxxxxxxx
> [mailto:foxboro-bounce@xxxxxxxxxxxxx] Im Auftrag von Johnson,
> Alex (Foxboro)
> Gesendet: Dienstag, 1. Februar 2005 23:54
> An: foxboro@xxxxxxxxxxxxx
> Betreff: Re: [foxboro] IACC Projects (was: IACC Projects)
>
>
> Invensys Process System employees are neither encouraged nor
> discouraged from responding to this list. I suspect that most
> have other things to do; I clearly don't have enough to do or
> lack a life.
>
> As for customers commenting on IACC, my belief is that most
> of the installed base does not use it and new customers are
> not on the list.
>
> With regard to Greg's questions, here are my answers:
>
> 1. How many folks are using IACC on a regular basis at this
> point? Lots, many internal IPS employees use it every day.
>
>
> 2. Do you consider it robust?
> I do. It has been heavily tested and is well documented. It
> is our preferred configuration tool.
>
>
> 3. Is it capable of handling a project of around 3000-4000
> I/O points? We are doing jobs today with over 90,000 blocks.
> I'm certain that IACC can handle a project this size.
>
>
> 4. How easy (or difficult) is it to backup/restore your IACC
> database? I can't comment specifically because I'm not a user myself.
>
>
> 5. Does IACC have bulk configuration import capability of
> either Excel- or text-formatted information? Yes. IACC has
> bulk import capability. I'm not an expert, but the details
> are in the manual. The manual is B0400BP.
>
>
> 6. Does IACC replace System Definition, or any other
> configurators, or just ICC? IACC can be used in place of
> SysDef as well as ICC.
>
>
> 7. Does a system configured with IACC still have a CSA database? Yes.
>
> CSA is used - principle function - to ensure uniqueness of
> top-level OM names (compounds). This does not change based on
> the configuration tool.
>
>
> 8. Any other general opinions/comments?
>
> You need to be at V6.4 or later. Certain model A stations are
> not currently supported.
>
>
>
> Regards,
>
> Alex Johnson
> Invensys Process Systems
> Invensys Systems, Inc.
> 10707 Haddington
> Houston, TX 77043
> 713.722.2859 (voice)
> 713.722.2700 (switchboard)
> 713.932.0222 (fax)
> ajohnson@xxxxxxxxxxx
>
>
>
> ______________________________________________________________
> _________
> 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: //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: //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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
