End User Council Ideas - Archive

[Stephen Mitschke]

Below is a summary of a number of ideas that have been bouncing around, notonly in my head but other folks as well that I have been aware of eitherfrom conversations in the hall at the General Assembly last week, or e-mailsover the past little while. What I would like to accomplish through thisposting are two things:1. See if there are more ideas out there so we can get them in the open.2. Try to find some way to prioritize all the ideas, once they are collectedso we can feed them back to the Foundation's End User Council and Board forpossible consideration/implementation.Here's the list in no particular order/priority.a) ITK Test & Power:- limits for power surge and dip when adding or connecting a device to asegment. How long can a device operate outside (normally below) thespecified 9 volts before it resets.- Lift off voltage limitsb) Power Supplies- Smart power supplies with an FF output (likely DI) to transmit theirstatus to the host and network.c) Valve PositionerDoes anyone see a need or possible requirement for redundant H1 connectionsto a valve positioner? This would allow a valve to reside on 2 segments andthen should 1 fail, the other segment would take over.d) Fieldbus Device IndicationSince most Fieldbus devices look no different than their analogpredecessors, other than perhaps a sticker on the outside, should there be aunique way to identify a Fieldbus device inside near the terminal strip?This can be a problem if existing wiring is reused for the new device sincethe Type A cable would not be present to serve as a clue. Something assimple as a sticker inside the transmitter may do the trick.e) Device DiagnosticsInclude information in the DD and CFF files on how the host can access anduse the basic Diagnostic/Maintenance type information they contain so itwill look 'pretty' in anyone's host or more importantly be accessibleCondition Based Maintenance System. (Someone suggested to me that thisshould be a TR submittal) The higher level diagnostics should be left to themanufacture specific systems as they need some competitive advantage. Ofcourse the difficulty then becomes, who defines the basic diagnosticsrequired. Any volunteers?f) Full Control System Interoperability and interchangeabilityThis means the ability to select any manufacturer's equipment that is bestin class to any manufacturer's other component that is best in its class.For example, I may want to use the redundant I/O of the one manufacturerwith the Operator interface station of another so that operators continuewith the interface with which they are familiar. This also means NOPROPRIETARY backbones or protocols anywhere in the system. HSE should makethis possible in the foreseeable future.Do any of you have others?ThanksIan- - - - -> c) Valve Positioner> Does anyone see a need or possible requirement for redundant H1connections> to a valve positioner? This would allow a valve to reside on 2 segmentsand> then should 1 fail, the other segment would take over.In talking about mimicking existing topologies, etc. This would be likeinstalling two network cards in a PC, or more like in a server. That way ifone of the network connections or cards failed, there would be redundancy.I see this as a significant value for critical applications in whichredundancy is of utmost importance, and especially if run under a 2-wiretopology in which losing communication also means loosing power. > e) Device Diagnostics> Include information in the DD and CFF files on how the host can access and> use the basic Diagnostic/Maintenance type information they contain so it> will look 'pretty' in anyone's host or more importantly be accessible> Condition Based Maintenance System. (Someone suggested to me that this> should be a TR submittal) The higher level diagnostics should be left tothe> manufacture specific systems as they need some competitive advantage. Of> course the difficulty then becomes, who defines the basic diagnostics> required. Any volunteers?This also would be very beneficial, and if implemented should be included inthe Host System Interoperability tests, I think. If we are trulyinteroperable I think that these basic diagnostic functions should beinteroperable as well. Not all the function blocks have to be the same, butthey need to be able to communicate to one another. To me this is part ofwhat interoperable should mean. If this does not work, it seems to me thatwe are settling for compatible, but not interoperable. Ben Larson- - - -A magazine editor with 30+ years of "previous life" process controlbackground has a thought or two. (See below)Of course you should take each with a grain of salt since all I have to dois write about this stuff; I no longer have to make it work.Dave Harrold> - Lift off voltage limits Dave: Shouldn't this be supplier provided data, like the ISA standards aboutlimits for operating, storage, etc.?> b) Power Supplies> - Smart power supplies with an FF output (likely DI) to transmit their> status to the host and network. Dave: It seems the ideal power supply would be FF savy and provideinformation about it's self in the form of digital communications.Technically it's doable but I don't know the price and market.> c) Valve Positioner> Does anyone see a need or possible requirement for redundant H1connections> to a valve positioner? This would allow a valve to reside on 2 segments> and then should 1 fail, the other segment would take over. Dave: I would think such capability would provide significant help whenworking through Safety Integrity Level issues.> d) Fieldbus Device Indication> Since most Fieldbus devices look no different than their analog> predecessors, other than perhaps a sticker on the outside, should there be> a unique way to identify a Fieldbus device inside near the terminal strip?> This can be a problem if existing wiring is reused for the new device> since the Type A cable would not be present to serve as a clue. Somethingas> simple as a sticker inside the transmitter may do the trick. Dave: Good idea and should extend to units that are getting their siliconchanged in the field to become FF. > f) Full Control System Interoperability and interchangeability> This means the ability to select any manufacturer's equipment that is best> in class to any manufacturer's other component that is best in its class.> For example, I may want to use the redundant I/O of the one manufacturer> with the Operator interface station of another so that operators continue> with the interface with which they are familiar. This also means NO> PROPRIETARY backbones or protocols anywhere in the system. HSE should make> this possible in the foreseeable future. Dave: This sounds like an "open" system as opposed to an interoperablesystem. I've been cautioning reader/users to be careful what they ask for in"open" systems, you might just get what you ask for. In the days ofproprietary DCS the operating systems, network protocols, etc. were theresponsibility of one supplier. If things didn't work, you had one butt tokick. With open systems the burden of making all the parts and pieces playwell together shifts to the end-user. A great many end-users (andintegrators) are incapable of taking on this added responsibility. (Ofcourse that assumes they even recognize there has been a responsibilityshift.)- - - - - - - - -Ian,My reply below...Ian,Here are just a couple thoughts...c) Valve PositionerDoes anyone see a need or possible requirement for redundant H1 connectionsto a valve positioner? This would allow a valve to reside on 2 segments andthen should 1 fail, the other segment would take over.In talking about mimicking existing topologies, etc. This would be likeinstalling two network cards in a PC, or more like in a server. That way ifone of the network connections or cards failed, there would be redundancy.I see this as a significant value for critical applications in whichredundancy is of utmost importance, and especially if run under a 2-wiretopology in which losing communication also means loosing power.KURT: The only way you will be able to pull this off is to have two separateH1 cards in the valve. This is feasible but could be rather expensive...e) Device DiagnosticsInclude information in the DD and CFF files on how the host can access anduse the basic Diagnostic/Maintenance type information they contain so itwill look 'pretty' in anyone's host or more importantly be accessibleCondition Based Maintenance System. (Someone suggested to me that thisshould be a TR submittal) The higher level diagnostics should be left to themanufacture specific systems as they need some competitive advantage. Ofcourse the difficulty then becomes, who defines the basic diagnosticsrequired. Any volunteers?This also would be very beneficial, and if implemented should be included inthe Host System Interoperability tests, I think. If we are trulyinteroperable I think that these basic diagnostic functions should beinteroperable as well. Not all the function blocks have to be the same, butthey need to be able to communicate to one another. To me this is part ofwhat interoperable should mean. If this does not work, it seems to me thatwe are settling for compatible, but not interoperable.Also, I was wanting to dialog with you, preferably over the phone, onexactly what the benefits were to being a registered (paying) member of theFieldbus Foundation as an end user. Several of us (engineers) are alreadynonpaying end users, but we are looking seriously at registering. I havebeen assigned to present the case for registration to our administration,and I thought that you would be a good source of experience in the matter.Thanks again.KURT: This is already implemented in the DD protocol and we test for it inHost Testing. It is up to the device vendor AND host vendor to support it.This is covered with DD Method and DD Menu. For generic diagnostics and calibration we have a specification called"Transducer Profiles" that is in Preliminary Specification (PS) stage.The Transducer Profiles currently cover 5 types of devices (Valve,Level, Flow, Pressure and Temperature) and a 6th (Analyzer) wasproposed. To move this document to Final Specification (FS) stage weneed working examples of each type of standard device transducer block.So far, we have had no volunteers to supply the standard transducerblocks. Maybe if the End Users were to pressure the device vendors...This is very easy for us to test in Interoperability Testing. We justneed to add the new test cases.-Kurt Zech- - - - - - March 15, 2001 - - - - Ian, my "end user" input (not as Board member input):1. Add to the Website all versions of the device tested and approved, notjustthe latest device version.2. I would like to see FF configuration tools standard requirements defined.Regards, Ron Szanyi- - - - g) Ian - I would like to add thatFoundation urgently needs to address all the 'missing I/O' that is availableinProfiBus but not Foundation.These include - encoders, proximity switches, motor speed controllers,power-cylinder/damper actuators, Motor Control Centre signals (overloads,running/stopped, star/delta, etc). Foundation needs to think about a cheapwayto get discreets (limit switches, solenoids, etc) on the network. The remoteI/Osoulution from some vendors offers no cost or integrity advantages at all.Foundations answer to ProfiSafe, the safety related fieldbus for safetysignals.A foundation approved 'DVM' that shows how many devices are active on thenetwork, if they are polarity sensitive, etc.Tom Nobes, British Nuclear Fuels Ltd.- - - - Another suggestion that I forgot in the first posting was to change the nameof the Host System Interoperability Test (HSIT) to Host InteroperabilityTest or (HI Test). HI Test is less likely to get confused with another 4letter (similarly spelled) word AND the word HI has many positiveconnotations.ThanksIan- - - Dear Ian,Indeed it was renamed "Host Interoperability Support Test" (HIST). Seehttp://www.fieldbus.org/neprd0301.htm#anchorhisthttp://www.fieldbus.org/histpg.htm#anchortopJonas- - -Hi Ian,Just to let you know, we have changed the name of the host testing to:Host Interoperability Support Test (HIST). As you know, I created theoriginal name in anticipation of the Marketing Folks coming up with abetter one. The name lasted longer than I anticipated...The "Powers That Be" decided that Host Interoperability Test is too"strong" of a name and could imply registration of a host, which is a"NO-NO".Keep in mind that the only thing done in the HIST is to "confirm that ahost has the capability of supporting certain Foundation fieldbusfeatures as defined by the HIST". Nothing more... Hence HostInteroperability "Support" Test...-Kurt Zech