Re: [foxboro] FW: More future direction questions.

  • From: "Johnson, Alex P (IPS)" <alex.johnson@xxxxxxxxxxxxxxxx>
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Thu, 13 Oct 2005 13:18:45 -0400

Re: We used NCNIs and the V7.X switches to replace the FONBEs in our 4
existing Nodebus segments.  Besides allowing us to install V7.X
stations,
this resulted in greatly reducing the traffic on our originally very
heavily
loaded single Nodebus system.

Good. I wish more people took advantage of this V7.x capability.


Re: Using an existing Nodebus segment to interface V8.X stations and any
CP270s to the V6.X/V7.X DCS portion of our system is going to raise the
Nodebus traffic impact on the Nodebus segment the ATS modules are
installed
in and could likely overload it - it is a big step backwards for us.

I'm not trying to minimize your request. It's not unreasonable, but
there
are reasons we did what we did and I'd like to present them so you can
understand what we were thinking when we designed a single ATS module as
opposed to two different ones.

So, here we go...

The various cases are:

1) Expanding a CBLAN network with a "new" Node of Mesh equipment
2) Moving a Node from a CBLAN network
      a) V7.x Nodes
      b) V6.x Nodes
3) Expanding a Node on a non CBLAN system
      a) V7.x Nodes
      b) V6.x Nodes

I believe that this is a complete set of cases. Now, I'll tell you how
we
think the equipment fits the cases. As in any system design, loading
must be
calculated to ensure proper operation, but I think we have you covered.

Case 1) Expanding a CBLAN Network
   Add a "bridge node" to the CBLAN Network. This Node consists of a 1x8
   with just a pair of CBLIs and a pair of ATSs in it. CBLI is hosted by
   a V7.x AW and ATS hosted by V8 AW70.
 =20
   This option allows the "bridge node" to handle all traffic between
the=20
   Mesh and the CBLAN networks. In this configuration, there is
considerable
   throughput.=20

   As Nodes are migrated to the Mesh (using ATS), the load here should
go up
   and then down to zero.

Case 2.a) - Moving a Node from a CBLAN Network for V7.x Nodes
   Put the ATS and a NCNI into a dedicated 1x8 - This segment handles
quite=20
   a bit of throughput (1000 packets per second). This option is ONLY=20
   necessary if the CBLAN's segment is overloaded which would be very
   unusual. The disadvantage is the cost and space of the 1x8.=20
  =20
   Or

   Put the ATS in a relatively unloaded segment hanging from a V7 switch
   usually the one which hold the CBLI. This is the nominal case. We=20
   believe that the traffic from any one node to the mesh is unlikely to
   overload a Nodebus segment segment since the CBLAN was handling it.

Case 2.b) - Moving a Node from a CBLAN Network for V6.x Nodes
   Put the ATS into a Nodebus segment on where the CBLI was.=20
   Since the CBLI's segment is functioning, using an ATS will not
   make it worse.

Case 3.a) Expanding a Node on a non CBLAN system under V7.x
   Put the ATS in a relatively unloaded segment hanging from a V7
switch.

   This is the nominal case; we are assuming that the Node segmentation
   has freed headroom on the segment.

   It is important to note that the traffic isolation is retained
   at both the ATS and the NCNI. That is, the only added traffic
   in the segment holding the ATS is data that is supposed to move
   into the Node. It is highly unlikely to overload a V7.x segment.


Case 3.b) Expanding a Node on a non CBLAN system under V7.x
   If you have used FONBEs, replace them with NCNIs (a good idea
   in any case) and add the ATS to the segment that sinks/sources
   most of the data going to the Mesh.

   It is important to note that the traffic isolation is retained
   at the ATS. That is, the only added traffic in the Node is supposed
   to move into or out of the Node. This situation is no different=20
   than adding a CBLI in the "old days."



So, for larger expansions - and CBLAN replacements - we recommend a
"bridge
node". For V7.x systems, we believe that most customers will have the
slot
space and lightly loaded segments. For V6.x system, we believe that the
use
of the ATS is no worse than the CBLI that was (or would have been) used
in
the "old days."

At the end of the day, we think we made a reasonable decision for the
vast
majority of the installed base.


Does this make sense?


Regards,
=20
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77063
+1 713 722 2859 (voice)
+1 713 932 0222 (fax)
+1 713 722 2700 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
=20

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On
Behalf Of Neil Martin
Sent: Wednesday, October 12, 2005 5:21 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FW: More future direction questions.





Alex,

We used NCNIs and the V7.X switches to replace the FONBEs in our 4
existing
Nodebus segments.  Besides allowing us to install V7.X stations, this
resulted in greatly reducing the traffic on our originally very heavily
loaded single Nodebus system.  Using an existing Nodebus segment to
interface V8.X stations and any CP270s to the V6.X/V7.X DCS portion of
our
system is going to raise the Nodebus traffic impact on the Nodebus
segment
the ATS modules are installed in and could likely overload it - it is a
big
step backwards for us. If 5 Nodebus segments are allowed, I understand
that
I can buy another 1x8 and NCNIs, try to find enclosure space, run fiber
to
connect the NCNIs to the V7.X switches, and then install the ATSs to
interface all the new V8.X stations and CPs to our system.  However, it
sure is a shame to have to revert to such means to do so - there will be
more potential failure points, we are having to utilize older
technology,
it seems the 10 MegBAUD Nodebus in the 1x8 is going to slow down
communications to remaining parts of our system (especially the V7.X
stations), it will cost more, etc.  It is a very big disappointment.


Neil Martin,    P.E.
Huntsman Polymers Corporation
2505 South Grandview
Odessa, TX.  79766
ph) 432-640-8436
pager)432-742-4289
email page)4327424289@xxxxxxxxxxxxx


=20


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