Re: [foxboro] Question on IACC database limit

Here's my advice:

1) Use SysDef not IACC for system definitions
2) Use an IACC server per plant area


The "5 database limit" is a misinterpretation of what is written in the
Release notes. Here's the text:
---------------------------------------------
This release of IACC has the following sizing guidelines for each
database instance:

 12,000 Blocks
   2900 Control Strategy Diagrams (CSDs)
    700 Compounds
    250 Fieldbus Modules (FBMs)
___________________________________
~16,000 Total Objects/Database
x 5 Databases
___________________________________
~80,000 Total Objects for 5 Databases

The above specifications are the limits at which IACC has been tested.
The application has been tested with up to 5 databases running
concurrently on a single IACC Server. Adding additional databases on the
server is possible depending on the resources of the server and the
activity usageof each database. If additional databases are required,
then incorporating additional IACC Servers is recommended and has
negligible impact on performance.

As for System Definition, my recommendation is that you don't use that
feature of IACC to maintain your system definition.

Rather, use SysDef to maintain the entire plant configuration and as the
source of your commit diskettes and the sink for your reconciles.

You would import this SysDef into IACC when you add new stations that
IACC needs to know about.
----------------------------------------------

You will notice that the 5 databases refers not to the maximum databases
on the server, but to the number of simultaneous users active on the
IACC server machine.


As for the SysEdit feature of IACC, I would recommend that for a large
job that you not use it. =


Large systems should use SysDef to define the configuration, create the
commit diskettes, and accept reconcile diskettes. This configuration
should be imported into IACC when new control stations are added.


I hope this helps.


Regards,

Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Adam.Pemberton@xxxxxxxxxxxx
Sent: Wednesday, October 24, 2007 7:18 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Question on IACC database limit

I'm sitting in an IACC course and we're discussing the issue of database
limits.
 =


The instructor has informed us that IACC can only handle a maximum of 5
databases. Given that any IACC database can also only handle 16,000
objects (usually blocks), this represents a total limitation of 80,000
blocks and given the real need to keep room for expansion and logical
grouping of CP's, means that more than 40,000 blocks total will become
very problematic. This represents only about 3 times our current system
and we are by no means a big Foxboro installation (approx 4 online
CP270's and 6 CP40A/B's).

 =


Questions are:

1.      Is this 5 database limit real? Surely they're just files on a
harddisk?
2.      If it is, how are big sites suppose to manage this?

 =


Another side issue is that IACC explicitly includes a system definition
and (from V2.1 onwards) performs all SysDef operations. This means that
each separate database should have a system definition for the entire
system, even though it will only contain the compound and CSD
information for a subset.

What's the recommended method for keeping each in sync, for example,
when a new CP or Workstation is added?

 =


Regards

Adam Pemberton

Lihir Gold Ltd


 =

 =

_______________________________________________________________________
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=3Djoin
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
 =



Confidentiality Notice:
This e-mail and any associated files are intended solely for the individual=
 or entity to whom they are addressed. Please do not copy it or use it for =
any purposes, or disclose its contents to any other person. Further, this e=
-mail and any associated files may be confidential and further may be legal=
ly privileged. This email is from the Invensys Process Systems business uni=
t of Invensys plc which is a company registered in England and Wales with i=
ts registered office at Portland House, Bressenden Place, London, SW1E 5BF =
(Registered number 166023).  For a list of European legal entities within t=
he Invensys Process Systems business group, please click here http://www.in=
vensys.com/legal/default.asp?top_nav_id=3D77&nav_id=3D80&prev_id=3D77.

If you have received this e-mail in error, you are on notice of its status.=
 Please notify us immediately by reply e-mail and then delete this message =
from your system. Thank you for your co-operation. You may contact our Help=
desk on +44 (0)20 7821 3859 / 2105 or email inet.hqhelpdesk@xxxxxxxxxxxxx T=
his e-mail and any attachments thereto may be subject to the terms of any a=
greements between Invensys (and/or its subsidiaries and affiliates) and the=
 recipient (and/or its subsidiaries and affiliates).


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