FieldComm Group Forums for FOUNDATION Fieldbus technology  

Go Back   FieldComm Group Forums for FOUNDATION Fieldbus technology > Public Forums > Fieldbus User's Network [FUN]

Fieldbus User's Network [FUN] The Fieldbus User Network List Forum. Post your fieldbus related questions here.

Thread Tools Display Modes
Prev Previous Post   Next Post Next
Old August 12th, 2003, 11:35 AM
Stephen Mitschke's Avatar
Stephen Mitschke Stephen Mitschke is offline
Admin / Fieldbus Staff
Join Date: Jun 2003
Posts: 472
[FUN] Foundation Fieldbus Drawing Representation - ARCHIVE

Attached is a JPEG file showing how we are proposing to do the new Segment
drawings. One drawing for each H1 Segment and it is similar to what is being
proposed by Raja. If anyone else has ideas or comments please send them on.
Ian Verhappen
-----Original Message-----
We are at the design stage of Foundation Fieldbus for our Causticisng Plant.
Causticisng Plant is part of our 850 Tonne/day capacity Pulp Mill. There
are about approx. 60 Instruments in the Causticising Plant FF system and we
are planning to have four segments. We have chosen Smar system 308 as our
host system. We would like to know whether to use the format of existing
loop drawings, Field-----> Field JB-----> Marshalling Box------>DCS or is
there any better way of representing FF instruments on drawings. All ideas
and suggestions are most welcome to my email address as shown below.
Raja Lokuketagoda
- - - -
This was merely a sample and is actually VERY Close to what we did on the
NRU. The reason to show the software on the loop drawings is that it was
decided by S5.1 that it should NOT be on the P&ID. The segment/loop drawing
represents how the segment is installed/configured and hence our reason for
showing this information here.
In response to your second question about InTools. Yes, they will be able to
generate 'automatic' segment drawings from the database.
Ian Verhappen
Syncrude Canada Ltd. MD 0032
P 780/790-4079, F -5190, cell 799-6017
-----Original Message-----
I do not agree with the proposed drawing. I agree with the layout of
having a complete segment drawing with all associated instruments but do
think we should be showing the "software" components on this drawing.
(Drawings are typically not updated with software changes and changing
control from the host to a field device can now be done quite easily.)
A database holding this information would be a much better solution.
(Would INtools be capable of holding this information in a method
that the segment drawings would be automatically updated?)
Sorry, I have been out of the loop on how UE-1 is handling some of
these items.
Are our "loop" drawings going to remain soft after UE-1, or will
they be transferred to Microstation?
Mike Achtemichuk
- - - -
I am sure you have this covered but I could not resist to stick my nose into
The drawing of course does not show the terminators and power supply. Since
I know that you know this, I wonder how the tech's will know to be sure
there is a terminator somewhere in the system. I assume the power is
provided from the FF interface card. The other quick question is the
grounding of the shield - where do you ground? Which end?
Now, just some "nice things" to think about on the drawing -
- power consumption for each device
- A device that has a LAS but is not active, same with PID, etc.
- total length of the segment = home run + each spur
- Device address - maybe a blank to write it in later / after assignment
Sorry to butt-in!
Thanks for listening -
- - -
In response to one of Chuck's comments, the intent was to show the
Terminator block differently than the expansion block, likely with a letter
T or a light on the block. Any suggestions from the list on this or Chuck's
other suggestions?
- - -
I would like to offer some of my thoughts on the content of a Segment
drawing. I agree on one drawing for each H1 segment. The drawing should
represent the physical aspects of the segment, for example, devices by
tagname, power supplies/conditioners and their circuits, expansion and
terminator blocks, host card, the type of the wiring used, approximate
wiring distances, locations of the devices where practical. This would
facilitate troubleshooting on the segment as well as for making additions or
other revisions.
Most of this data is "static" in nature and will change infrequently, if at
all. I would avoid putting more dynamic type of data such as calibration
settings, model numbers, etc. on the segment drawing because these change
more frequently and then you would have one more document to worry about
keeping up to date. Most or all of this data is readily available from the
host system.
Also, I would not call it a Loop Drawing. One segment can have several
"traditional" loops on it. This way we can keep the terminology straight.
Gary Addison
- - -
Dear Ian,
I agree with Gary Addison's approach.
1. Instead of "loop drawing" or even "segment drawing" I would call it
"network drawing" since you would most likely make one drawing for the
entire network (all that comes out of one communication port). E.g. a
network for intrinsic safety may consist of one safe area segment and four
repeating safety barriers with one hazardous area segment each, total of
five segments connected to one interface port.
2. Only "static" stuff. I.e. include hardware like a terminator but
not software like PID or Link Master functionality. E.g. you may shuffle
around the blocks to execute elsewhere or even add blocks. When you replace
devices you may add or lose the link master capability etc. These soft
functions are already well documented by the configuration tools so you
could print out (or export to Excel) a cross-reference list of this from
there and it will always be updated because you are automatically
documenting as you configure. If soft functions are included in a drawing
made in another software package there is a risk you forget to update it to
"as built".
3. I prefer the plain "host" term (from HSE spec. and ISO FMS) as
opposed to
"host system". Because Fieldbus integrates all parts so well, the "system"
is no longer an island separate from the "field devices". I.e. the "system"
is the whole thing including both host, networking and field devices.
- - - -
I believe that each segment should be identified by a group of x characters.
Something like:AAUUNN, where AA can be area, UU unit and N sequential
number. Each ancillary device would receive the AAUUNN-T1 for terminator 1,
AAUUNN-JBxx for the junction boxes, etc.
The LAS indication is OK in the wiring diagram, but I am not so sure about
the function blocks. They should be in the functional diagrams, where the
association with the physical device can be made. Quiescent current an
important information.
The Terminator should be clearly identified by a different color, text or a
big T. I don't like terminators in the devices. Removal of the device would
cause inadvertent removal of the terminator.
Approximate cable length would be a good optional information, mainly if IS
being used.
The diagram should contain all devices in the segment, their tags, Junction
boxes or t's that they are connected to and the relative position of the
Plants with pre determined instrument installation stands could have
Installation stand location/identification.
The functional diagram would contain the function blocks functionally
connected and their instrument location.
- - - -
Attached is an example of how H1 loop will probably look for AOS
project. Need was to generate loop drawing from INtools and also have
similar look to conventional analogue loops (we'll only have about a 30%
H1 loops).
Gordon <<AOSLOOP.PPT>>
- - - -
Attached is a loop drawing for a FF installation. I have some questions on
drawing symbols that should be used on P&ID's. I have contacted ISA and
tell me that they do not have any standard symbols to be used on drawings
for FF
installations at this time and that they are working on such. Do we use the
dashed line (electric) or should we go with the Data link line symbol (line
small circles) to represent the wiring between devices. How about the device
symbol since ISA hasn't come up with one yet. Sq. Box with circle inside
horiz. line or hexagon. or how about a new one sq. box with hexagon
Maybe we use the DCS symbol and just right "FF" beside it. Everyone here has
different ideas. I realize that ISA will eventually come out with one but we
need a std. symbol now. Any ideas??
<<Mac Word 3.0>>
- - - -
I agree with Chuck that it is a good idea to include the segment length
information on the segment drawing but think the other information he
suggests be on either the data sheet or some other database.
- - - -
[Verhappen, Ian] To answer this question and an earlier one about
InTools/database FF information on a drawing:
1. InTools version 5.1,due out in the next few months supports an
automatically generated simplified segment drawing.
2. Most CAD packages support 'scripting' to link the drawing to an external
database, thus making it possible to generate segment drawings on demand
once a template to map the fields to the appropriate area and drawing level
have been created.
- - - - -Original message - - - - -
1. Keep the name segment drawing, in case of the example below there
are additional spurs, and no additional segments.
2. For either mechanical or electrical maintenance knowledge of the
BLAS is required. I suggest to show this functionality on the segment
drawing. It would be beneficial of having a dynamic import/export connection
to a tool like INtools to keep the information current at all times.
Richard Willems
- - - -
To answer Richard's questions about symbols on P&ID's, ISA is not planning
to differentiate via the P&ID bubble between a Fieldbus device and a
non-fieldbus device. The reasons are as follows:
- do we then develop a different symbol for each type of smart device? (i.e.
HART, Profibus, FF, etc.?)
- Fieldbus will NOT change the function of the device on the process. A
temperature Tx will still measure temperature and a valve will still open
and close to control flow/pressure.
- the 'loop' (I mean segment) diagram will be used for troubleshooting
field/device problems so it is here the technician and engineer will need to
know what type of devices are installed and how they affect control.
The ONLY change I think that will happen to P&ID's will be the use of the
following interconnecting symbol to show a fieldbus communication link
between devices and/or host systems.
IF you are diligent about using the above interconnecting line for all your
fieldbus devices, you will know in this way that the device is fieldbus
- - -
I think we should keep the conventional symbols used on P&ID's, as
Ian said a Tx will still be a Tx and a valva a valve, but in the
other hand we must identify the function blocks in each device so the
control strategy.
This will be a good challenge.
Rick Castaņeda
- - - -
Thanks for the reply. Agree with the field instrument symbol (bubble) not
changing. My question was really for the Honeywell DCS symbool vs. the
PC/Controller symbol, but the same philosphy could apply here as well.
- - - -
Dear Ian,
I'm coming in late in this discussion... anyway here are two points that may
or may not be relevant:
1. FF distinguishes between PD_TAG (physical device tag) which is the
tag of the device as a whole and FB_TAG (function block tag) which is the
tag of just one block. I would use the PD_TAG in the Network diagram
(formerly loop diagram) and the FB_TAGs in the P&ID. Just like the P&ID
previously did not shown which CPU card a block was in I believe it will not
be shown in the P&ID which FF device the block is in.
2. There are perhaps two different kinds of multivariable transmitters.
One is the spruced up pressure transmitter with three sensors for DP+P+T
which is not really used to make three measurements, but rather to calculate
just one being mass flow or normalized volumetric flow. I imagine such a
device will often be represented only by a single AI block (for flow) in the
configuration tool and therefore a single bubble in the P&ID will do. I
believe that DP+P+T will exist only as three or possibly one transducer
blocks, not function blocks. (I see only function blocks in P&IDs because
resource blocks and transducer blocks are device configuration, not control
strategy configuration).
The other type of multiple variable device is more of a multiple
channel device, such as many FF temperature transmitters that make two
measurements which generally are independent (although can be used in a
redundant scheme etc.). Just like a box was not drawn around measurements
done in the same card, I think it will not be done around measurements from
the same FF device.
- - - - - - -
This sounds reasonable, however it is a bit of a problem in my circumstance.
We are a reasonably small chemical company, and don't have a great many
control loops, being mainly batch processes. So we don't have loop diagrams.
The P&ID is really it as far as information goes. I would be using FF mainly
for the field wiring aspect for tanks etc with level, temperature and a lot
of discreet valve opening devices.
If I don't show all the info on the P&ID, it won't be seen (by the
instrument techs/electricians doing work) . Unfortunately I can see this
leading to a very cluttered P&ID. I might have missed a couple of earlier
emails if they addressed this.
Any thoughts?
BTW, I am an Engineer (Mech,projects) so my instrument knowledge is only
what I've seen here and at my previous company. The P&ID was about all that
I ever saw. ie I might have some pretty big gaps in my knowledge.
- - - - - - - -
Like Jonas, I am coming in somewhat late on this discussion and have found
it interesting to read through everyone's opinions. After discussing this
internally with a few people, I agree with Herman that this is "cat herding"
at its finest.
I see two main threads to the discussion - how to represent multivariable
devices in general and how to represent fieldbus devices (including FF),
multivariable or not.
Multivariable devices have several forms and include HART and fieldbus
types. These should be depicted differently, using standard electrical
connection lines for HART and something different for a fieldbus - perhaps a
dashed line, with the letter "B" for buss, superimposed over it. Use
standard symbols, such a circle for a field device, tag it with the
multifunction [U], and denote the functions using text labels next to the
symbol to reduce drawing congestion. Anything more complex than this can be
shown on a reference drawing.
I agree with the majority comments about showing the control scheme and not
physical connectivity. The critical relationship is between the
measurement(s) and the final control element and, from the P&ID, it doesn't
matter what other sets are on the same wire. That would be depicted on the
segment drawing. About the only thing that you would want to do is to
continue to differentiate one type of signal from another. The normal dashed
electrical line should be used on fieldbus devices because they are still
hard-wired electrical connections. A superimposed symbol or letter would
differentiate from analog electrical. If desired, I think it is possible to
show the PID algorithm in the field device by using standard ISA
conventions. In a valve you could show FCY instead of FY or FCT instead of
FT in a transmitter.
I have added some alternate ideas (just rough sketches) to your Powerpoint
drawing relating to HART and fieldbus.
I also think that a subtle shift in thinking is necessary with fieldbus.
While we may say that the P&ID shows logical and not physical connections,
the physical connections of analog pneumatic and electrical devices were
always implied by their point to point nature. We have gotten used to
interpreting and troubleshooting from the P&ID based on these implications.
With fieldbus it is possible to chain several devices on the same wire and
this will upset some assumptions about interactions, redundancy, etc. Just
something to be aware of.
Overall, I think we should try to maintain some kind of "workability"
balance (for lack of a better word) with P&IDs. They need to be both as
simple and as explanatory as possible for all who need to use it - managers,
engineers, operators, technicians, inspectors, etc. Many control and logic
schemes are so complex that they cannot be effectively conveyed on the P&ID
without making it useless as a visual aid. Drawings will be easier to
maintain if functions remain separated instead of being shown multiple times
on different drawings. A somewhat contradictory point is, that the P&ID is
typically a "controlled document" while loop sheets, control descriptions
and other instrumentation drawings are not. Therefore, the P&ID needs to
have as much information as possible to prevent day to day working drawings
becoming "controlled documents". It's a matter of striking the right
Gary Addison
Equistar Chemicals LP
Control Systems Engineering
Channelview, South Admin III # 347
- - - -
Just to let everyone know, that ISA 5.1 is leaning towards the following for
representation of digital communications on P&ID's
- fieldbus signals will be a dashed line with filled in circles.
- other serial communications (i.e. Modbus) will be a dashed line with open
circles (same symbol as today)
P.S. This comment also applies to Jim Spragues FF standard document.
Attached Images
File Type: jpg Segment_dwg.jpg (78.5 KB, 933 views)
Attached Files
File Type: ppt AOSLOOP.PPT (65.5 KB, 955 views)
File Type: doc deltav.doc (85.0 KB, 792 views)
File Type: ppt Sec_4_9.ppt (157.5 KB, 859 views)


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[FUN] FF Cable Types and Calculations - ARCHIVE Stephen Mitschke Fieldbus User's Network [FUN] 3 June 10th, 2008 10:37 AM
[FUN] Ammonia Plant Installation - ARCHIVE Stephen Mitschke Fieldbus User's Network [FUN] 2 April 22nd, 2007 12:56 AM
[FUN] FF Data Sheets - ARCHIVE Stephen Mitschke Fieldbus User's Network [FUN] 1 May 17th, 2006 08:53 AM
[FUN] FF Control Algorithms - ARCHIVE Stephen Mitschke Fieldbus User's Network [FUN] 0 August 12th, 2003 11:10 AM
[FUN] Representing Multivariable Tx on P&ID - ARCHIVE Stephen Mitschke Fieldbus User's Network [FUN] 0 August 12th, 2003 10:47 AM

All times are GMT -5. The time now is 02:07 PM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
(c) 2011-2015 by FieldComm Group. All rights reserved.