[foxboro] Understanding InFusion

Alex,

    Thanks for your explanation.  It breaks down the details of the  IEE 
as well as Infusion View HMI.  It was very useful to help my simple mind 
understand how the pieces and parts fit together.  My original questions 
were confusing because I mixed the IEE and Infusion View pieces together 
as if they were all part of a central database used by the InFusion 
product line.  I think I understand now that this is not the case.

    I never used Wonderware's InTouch as an HMI, but always thought that 
the way it worked was to establish multiple API interfaces with many 
different systems from multiple vendors, (plc's, DCS's), then read real 
time data from the disparate systems into an InSQL, (quasi-realtime), 
database that served the data to any application that needed it.  i.e. 
the InTouch HMI, the historian, the alarm subsystem, the control 
configurator, etc..  It also allowed InTouch users to write back things 
like setpoints, outputs, mode changes to controllers, using the reverse 
path, InTouch to the InSQL database, through the API back to the PLC's 
and DCS's.

    I thought InFusion View was really just the InTouch HMI for the 
Infusion system and that it would not make direct Object Manager calls 
as Foxview and DM do today to individual CP's, but rather just get 
served data from the centralized tag server / the quasi-realtime database.
  I now think I understand that InFusion View is, InTouch + special 
Infusion add-ons, that allow it to talk directly to the IA stations via 
the Object manager.  Is that correct?

In addition to that, I realized there needed to be a configuration 
database for the IEE.  I wondered if this was also part of a 
centralized, served, database that remote clients could read from and 
write to in order to make much more granular configuration changes than 
are allowed with ICC/IACC.  I'm still not sure about this.  Is it 
possible to make IEE changes to individual blocks / parameters in the 
control database without locking the entire controller, compound, or 
database from other users?  It sounds like you can also use DirectAccess 
.xml calls to make these modifications.  A little more clarification on 
this would be helpful.

I think I understand that 3rd party packages like Limeware's Foxray will 
still be able to gather information to do their work using DirectAccess 
and not be dependent on Integrity as I surmised in my previous email.  
Users will also be able to use DirectAccess to get info from the 
proprietary IEE database.  Jeremy shared that the DirectAccess details 
are available in B0750BM so I can RTFM if I need to know more. 

Are there any users out there on this list using InFusion?  Does anyone 
have experience with DirectAccess?

I was also curious to know if changes in one database are propagated in 
a relational way to the others, (i.e. range changes to an analog input 
made in the control configuration database will automatically be 
recognized in the historian/alarm/display/instrument applications.)  I 
think your answer to that is no, but I am asking again to be sure I 
understand.

Is there any Invensys directive for Triconex to fit into the InFusion 
environment as a native part of it?  For instance, will you be able to 
configure a Trident or Tricon in the IEE or will that still be done in 
their native Tristation 1131 application with real time values 
communicated through an IA TSAA gateway?

Regards,
Tom
 
Johnson, Alex P (IPS) wrote:
> ArchestrA is a set of tools and technologies used to build products.
>
> IPS took ArchestrA and other WW technologies and developed four products
> collectively known as the InFusion Enterprise Control System.
>
> The InFusion ECS consists of:
>
> 1) InFusion View (HMI)
>    WW's InTouch plus an IPS created InTouch application. Collectively,
>    they are called InFusion View. Out of the box, InTouch doesn't do 
>    much. The InFusion View application gives the basic framework
>    (menus, detail displays, whatever) expected in the DCS market.
> 2) InFusion Historian (Historian)
>    WW's InSQL without any significant changes, but used in MDAS mode
> always.
> 3) InFusion Application Environment (Application Platform)
>    WW's Industrial Application Server enhanced to handle some specific
>    IPS needs.
> 4) InFusion Engineering Environment (Configuration Tool)
>    WW's Integrated Development Environment extended to include support
>    for I/A Series Controllers as well as the InFusion Application
>    Environment (IAE) 
>
> The IEE then is a configuration tool that can configure two "controller"
> types:
>
> 1) The I/A Series CP270s (and soon older CPs)
> 2) The InFusion Application Environment
>
> With this in mind, I'll try your questions:
>
> Re: Does the Invensys IEE offering use Wonderware's InTouch as its HMI?
> No. 
>
> The IEE is a configuration tool like ICC, ICC Driver Task, FoxCAE, and
> IACC.
> It is not a primary human interface for operators. 
>
> InTouch is a real-time HMI similar in purpose to FoxView in that it
> supports plant operations not control system implementation.
>
> As IEE grows, it will support configuration of InTouch within its scope,
> but it does not use InTouch at all.
>
>
> Re: If not, is the IEE HMI directly accessing data from the 
>     Foxboro Object Manager in the same way the DM and Foxview do today?
> DM/FV are primary operator interfaces and make direct OM calls to
> achieve their purpose. 
>
> Though it is not an operator interface, the IEE supports real-time,
> animated loop diagrams as does IACC.
>
> To provide this support, it does get its data from the OM.
>
>
> Re: Or is there an API database that collects/stores real time values
> from 
> the object manager and then serves that data to the HMI and any other 
> applications that need the real time info?
>
> Okay, I'm getting the drift of your questions.
>
> The real-time HMI is InFusion View; not the IEE.
>
> InFusion View gets its data directly from the CP; there is no
> centralized tag server in the InFusion ECS implementation of InTouch.
> Rather, each workstation goes to the CP for its data independently.
>
> Applications running in the same box with InFusion View can share data
> with InFusion View, but applications in different boxes will have their
> own data feeds.
>
> Maybe this highly detailed picture will help:
>
> CP270   -> MESH -> AW70
> BP-> OM ->         OM -> IADAS -> IV
>                                -> Other Apps
>
>                 -> AW70 / WP70
>                    OM -> IADAS -> IV
>
> Re: Is the the real-time process data, process historical data, and the 
> control configuration data all stored in a relational SQL database?  Or 
> are there multiple, non-related databases used for these purposes?
>
> Real-time data resides in the I/A Series Object Manager.
>
> Historical data resides in InFusion Historian. InFusion Historian - like
> all other plant historians - uses flat files to store raw data and makes
> it available for various users through SQL Server queries.
>
> Configuration data is stored in itsown SQL Server database; it does not
> share a database with InFusion Historian though the two applications
> could share the same instance of SQL Server.
>
> Does this help?
>
>
> BTW, I'll be giving a lecture on Day 1 of the NA User's Conference on
> "InFusion for the Installed Base." Guess what kinds of question, I'll be
> covering.
>
> In fact, if you have specific questions, send them to me.
>
> September 20-24, 2009
> 2009 IPS North American Client Conference
> Houston, TX
> http://ips.invensys.com/en/aboutips/Pages/nacc2009.aspx
>
>
>
>
>
>
> Regards,
>  
> Alex Johnson
> Invensys Process Systems
> 10900 Equity Drive
> Houston, TX 77041
> +1 713 329 8472 (desk)
> +1 713 329 1600 (operator)
> +1 713 329 1944 (SSC Fax)
> +1 713 329 1700 (Central Fax)
> 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:             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: