Re: [foxboro] Infusion with I/A series DCS
- From: "Johnson, Alex P \(IPS\)" <alex.johnson@xxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 21 Jan 2008 22:32:02 -0500
Re: So, under InFusion, what will be the best way to provide a large
number of remote HMIs for management/supervisors/remote operators? =
Best is a relative term that you will have to decide given the right
information.
There are two approaches:
1) Use InFusion Terminal View - our MS Terminal Services approach
2) Use generic InTouch instances that get data from an InFusion
workstation.
The first approach can support 3 to 6 remote sessions per P91 box.
The latter approach can support more instances of InTouch. However,
there are two issues:
1) I don't have performance numbers to back up that statement though I
believe it is correct.
2) Generic InTouch instances do not have some supporting infrastructure
required to run the InFusion View application.
Re: What do you mean by the term "InFusion View application?" Do you
mean the executable? [I'm anticipating the next question here - AJ]
InTouch does not run process graphics like FV does. For FV, each
display/graphic is in its own file and is distinct from all others. You
load the files that you want a FV instance to see on your workstation
and make sure that a menu makes it accessible.
InTouch (and InFusion View) take a totally different approach. InTouch
loads an "application" that contains lots of things besides process
graphics, a.k.a., InTouch Windows. InFusion View is one such
application.
You may add InTouch Windows to the InFusion View application that we
ship and make other changes, but we do have some items in our
application that depend on our workstation software. If you try to load
InFusion View into an InTouch instance on a generic PC some things will
not work.
Re: What features of InFusion View will not work? [More from me - AJ]
I don't know. I've never tried this, but I suspect that the InFusion
View application makes OM calls.
Re: So, what does this mean to me? [More from me - AJ]
Well, it depends.
You should be able to setup generic InTouch workstations that get their
data from the IAE in an InFusion View workstation assuming that you
build a new generic application and the associated InTouch windows.
However, this application would not be the one you are running on your
InFusion workstations. It would be similar but it would be different.
This may or may not be a significant amount of work to maintain.
Re: What is my alternative? [more from me - AJ]
The alternative to remote, generic InTouch instances is to use InFusion
Terminal View. InFusion Terminal View is a MS Terminal Services based
remote access license.
However, this approach you will get only 3 to 6 remote InFusion Views -
actually InFusion Terminal Views - before the machine bogs down. =
For 50 user's you'd need a lot of machines if they are all active at the
same time.
Re: What do you recommend? [more from me - AJ]
If you want to use InTouch, the simplest choice is InFusion Terminal
View, but it could be expensive to setup.
The generic InTouch approach would (probably) require fewer servers, but
it will require more maintenance to support.
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 Kevin Fitzgerrell
Sent: Monday, January 21, 2008 8:59 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Infusion with I/A series DCS
OK, I think I'm getting there.
So, under InFusion, what will be the best way to provide a large
number of remote HMIs for management/supervisors/remote operators? We
normally serve around 50 simultaneous remote DMs now, and have had to
split that between 4 workstations because of the 16 DM/FV limit per
workstation. I'd prefer to have all the remote displays (at least for
management) served from a single server (easier to administer and
lower loading). Is there a way to do something like that with
InFusion? Does the web based server have lower load per instance?
Most of our users are OK with PI/Processbook for visualization, but
I'm left with the 50 or so where I require actual plant HMI.
Regards,
Kevin FitzGerrell
On 1/22/08, Johnson, Alex P (IPS) <alex.johnson@xxxxxxxxxxxxxxxx> wrote:
> Re: Just to confirm - with Infusion, each InFusion View workstation
has
> it's own internal tagserver, correct? =3D
>
>
> Actually, each workstation has its own InFusion Application
Environment
> supporting the DIObject and DAServer required to access I/A Series OM
> data. This is equivalent to a tag server in each box, but the approach
> is different.
>
>
> Re: And if I wanted to set up a traditional tagserver feeding multiple
> InTouch instances (for example to replace an old WP providing 16 DM
> instances for managers and supervisors) that is possible, but will
> require a non-standard license.
>
> I would not care to bet on how many InTouch instances can be supported
> by an InFusion Application Environment. I doubt that we test that
> configuration.
>
> In any case, a remote InFusion View/InTouch instance could get tag
data
> from an IAE in a workstation using OPC.
>
>
> Re: Any word about migration tools? Either for graphics or for
> historian data?
>
> No specific migration tools are planned at this time. InTouch has to
add
> a large number of features before such a tool would be practical.
>
> AIM*Historian configuration can exported today, but InFusion Historian
-
> in normal mode - is configured from the IEE built control blocks by
> setting an attribute on the parameters that you want to records so I
> doubt that exporting the tag list would be of much value.
>
> AIM*Historian collected data can be exported using AIM*Oracle Export
> product. This basically puts it into a text file. I don't know if
> InFusion Historian could read that and associate with a tag.
>
>
>
> 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
=
=
_______________________________________________________________________
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=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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
