Re: [foxboro] Understanding InFusion

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

Sort of.

Typical InTouch implementations get their data from either:

1) Direct reads from an I/O Server (NetDDE, SuiteLink, OPC, etc.)
2) An InTouch tag server which handles the I/O Server and communications
and distributes the data to those that want it.
3) Industrial Application Server (IndAppSvr) Application Objects (AO) -
Think AW70 Integrator with 100% user defined blocks.

The InFusion implementation places an instance of the IndAppSrv -
actually the InFusion Application Environment (IAE) - in each and every
workstation. InFusion View is smart enough to look to its local IAE for
its I/A Series data. This approach eliminates the single point of
failure and/or long failover times associated with intermediate
databases.


Re: InSQL database
The software between InFusion View (or InTouch for that matter) and the
data source has never been InSQL. InSQL is a plant historian like
OSIsoft's PI, AspenTech's IP.21, or IPS AIM*Historian. 


Re: InFusion View ... would not make direct Object Manager calls 
as Foxview and DM do today to individual CP's

We could have added the OM to InFusion View, but there are advantages to
the approach that we have taken that made the embedded IAE in the
workstations the better approach.


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

Yes. The control strategy is the unit of granularity. The user checks
in/out control strategies.

A control strategy is a collection of I/A Series control blocks
contained within a single compound. 

For sake of argument, you can consider it a control loop.


Re: It sounds like you can also use DirectAccess .xml calls to make
these modifications.  A little more clarification on this would be
helpful.

I'm not sure what to add. 

There are no ".xml calls;" rather, there is an XML file that defines the
actions to be executed by the DirectAccess execution engine. Think ICC
Driver Task script and the ICC Driver Task.

The best suggestion is to Read The Foxboro Manual (RTFM).


Re: 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.)  

Not that I'm aware of.


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

There is a strong desire to have one configuration tool for everything.
However, integrating the configuration of Triconex safety controllers
into the I/A Series controller configuration environment is an
interesting topic of conversation. 

I'll mention one issue - maintenance of segregation between the safety
system and the I/A Series system. A shared environment might compromise
that segregation. We consider the segregation of our solution to be a
high value feature. Something to think about as you consider SISs going
forward - how independent are they really?


Re: real time values communicated through an IA TSAA gateway? 
We do that today. The I/A Series TSAA gateway is a CP/FDSI and we do
that today.


Hope this helps.

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


** Confidentiality Notice:
This e-mail, including any associated or attached files, is intended solely for 
the individual or entity to which it is addressed. This e-mail is confidential 
and may well also be legally privileged. If you have received it in error, you 
are on notice of its status. Please notify the sender immediately by reply 
e-mail and then delete this message from your system. Please do not copy it or 
use it for any purposes, or disclose its contents to any other person.

This email is from the Invensys Process Systems business unit of the Invensys 
Group, a group of companies owned by Invensys plc, which is a company 
registered in England and Wales with its registered office at Portland House, 
Bressenden Place, London, SW1E 5BF (Registered number 166023).  For a list of 
European legal entities within the Invensys Group, please go to 
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77.  

You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail 
inet.hqhelpdesk@xxxxxxxxxxxxx This e-mail and any attachments thereto may be 
subject to the terms of any agreements 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: