[FUN] ITK & Upgrades

[Stephen Mitschke]

Good'day Ian, One of our end users has raised a curly question which is agood subject for the "fun" network.This whole issue arose from an early FF adopter wanting to upgrade a FFHOST. Vendor 'X' is saying they require all existing instruments to meetInteroperability Test Kit (ITK) 4.0 to allow their system to talk to theinstruments from other vendors.The following is a real story;Host Vendor 'X' has finalised testing of all FF instruments with theirlatest revision of hardware and software. They have found 8 fieldinstruments that do not talk to their system. What is surprising is thatthese instruments were supplied at least a year after the ITK 4.0 tests werereleased. The instruments will require new motherboards/transmitters tobring them up to ITK 4.0. To do this is going to cost A$70K!! This is onlythe start of the ongoing costs as there are other units with the sameinstruments.Some of the other instruments can be upgraded by flashing the memory.If this is the case as an FFEUC we see this as a real concern.Our question is "Is there a standard from the Foundation in regard tohaving instrument suppliers having to have an easy upgrade path i.e..,instrumentation being able to be flashed EPROM upgraded- or should we beinsisting on downward Host compatibility?". We do not wish to be in the situation where actual hardware has to beupgraded with every new ITK being released, in fact we wish to havedownward compatibility so that we do not have the cost and heartache of evenhaving to upgrade to a new EPROM. This whole issue will be an ongoing problem if the situation actually is asdescribed. Every time a major upgrade to the Host is required, instrumentsmay have to be upgraded to comply with the latest ITK. We would have thoughtthere should be some backward compatibility, with only loss of features ifthe customer were to retain older versions of instruments. As ITK 4.1 hasrecently been released companies do not want to be in the same situation acouple of years down the track having to fork out huge sums of money tomaintain compatibility. Additionally field instrument vendors should not bein a situation of having to release products with the latest ITK version.We look forward to hearing responses that will address our concerns.Kind Regards to all,Jim RussellCo-ChairFoundation Fieldbus End User Council Australia

[Stephen Mitschke]

Hi Jim,My reponse below..."Verhappen, Ian" wrote:> > If this is the case as an FFEUC we see this as a real concern.> > Our question is "Is there a standard from the Foundation in regard to> having instrument suppliers having to have an easy upgrade path i.e..,> instrumentation being able to be flashed EPROM upgraded- or should we be> insisting on downward Host compatibility?".It is really up to the device vendor on how they handle upgrades, if thedevice can be upgraded at all. The FF specification doesn't "require" anupgrade path for devices. But, to facilitate easy upgrading, we havecertain features defined in the spec to help:1) Upload/download capability from host to device. This is done directlyon the H1 segment. This is a defined FF spec feature that has beenpatented (FF has patent rights) and is available to all device/hostdevelopers. It is also part of the HIST feature tests.2) Partial DD's. DD addition's can be easily added to an existing DD.This is also part of the FF spec.> This whole issue will be an ongoing problem if the situation actually isas> described. Every time a major upgrade to the Host is required, instruments> may have to be upgraded to comply with the latest ITK. We would havethought> there should be some backward compatibility, with only loss of features if> the customer were to retain older versions of instruments. As ITK 4.1 has> recently been released companies do not want to be in the same situation a> couple of years down the track having to fork out huge sums of money to> maintain compatibility. Additionally field instrument vendors should notbe> in a situation of having to release products with the latest ITK version.We at the FF are well aware of this situation and have safeguards inplace for revision handling with the spec, ITK, etc.1) Currently the ITK is frozen. Only minor revisions that do not affectthe capability/behavior of a device may be added/changed (things likebug fixes,addtional tests for existing functionality, etc.) The current version ofthe ITK is 4.01. 4.01 was released a year ago and included two minorchanges (one change was a way to handle a device with many VCR's, theother change was for a specific vendor to implement an optional feature)that did not affect any registered device. Technically there is no realdifference between ITK 4.0 and 4.01.2) If there is a change to the FF specification that will cause a deviceto implement new behavior, than what is currently tested with ITK 4.x,then the ITK must undergo a MAJOR version change. This MAJOR ITK versionis noted in the Resource block under ITK_VER. Currently all 4.x deviceswill have "4" for the ITK_VER. The devices that would be registeredunder ITK 5.x, would have ITK_VER = 5. This enables any host to quicklydetermine if a device has new behavior.3) Changes to the spec. Currently no changes are allowed to thespecification unless they are a clarification or fix. No "new"functionality that would effect all devices would be allowed, unless itdeals with safety.4) I suspect that some host vendors are not telling you the whole story.Any host that can support a 4.x device _can_ support a previous device.There were only two major things that were changed with the release ITK4.0 one change added the ITK_VER to the resource block (no affect tointeroperability) the other change dealt with the alarm summary (noaffect to interoperability), but both changes contain new behavior,hence 4.0. In addition we added testing for the Capability file (CFFfile). If a device vendor created a CFF file for a previous device rev(prior to 4.x) it should work just fine. THERE WERE NO HARDWARE CHANGESREQUIRED FOR ANY ITK 4.0 DEVICE! So I would question why any devicevendor had to put in new boards to be compliant with ITK 4.0. If any of you have questions about the ITK, spec's things like that,please let me know.Regards,Kurt ZechManager, Technical ServicesFieldbus Foundation

[Stephen Mitschke]

To all,The lack of consistent upgrade capability in existing installed FF devicescan cause problems if host systems discontinue support for older devicesoftware versions. Because of this it is important that the host notdiscontinue support of released versions of device software. As new hostsoftware is released the host should be tested with all old versions ofdevice software to ensure they continue to work as expected. This is theapproach Emerson has taken with DeltaV. All released device softwareversions (regardless of device vendor) supported in all prior versions ofDeltaV are supported in the latest release of DeltaV software. All releaseddevice versions are retested with the newest DeltaV software release priorto that DeltaV software version being released. This way device softwareupgrades and host (DeltaV) upgrades are decoupled. End user feedback on this approach would be appreciated.Tom WallaceEmerson Process Management

[Stephen Mitschke]

Tom:I understand and agree with this position for DeltaV or any other systemsthathave been around for a long time. I think this is what the end-usersexpect.But if a vendor is just entering the market with a new FoundationFieldbus-capable process automation system, I am not sure that a requirementthat they be able to support all previous devices is a fair expectation, nordoI think it is an actual requirement from the end-user (for example, me). Idon't want to pay for this.For example, if a new company (AbliCom, I will call them) is developing anew FFsystem, and I decide to purchase their system, it will be with new FF fielddevices. Almost all FF field devices currently for sale are ITK 4.01, sothatis what I will purchase and have on my project. I won't be buying anAbliComsystem to upgrade an existing FF process automation system - realisticallyFF istoo new. But from their first release on, I would expect that all futureAbliCom systems would continue to fully support ITK 4.01 and all futureupgrades. AbliCom would need to do all backward compatibility testing fornewhost software upgrades, for ITK 4.01 and later field device revisions.Jim ReiznerProcter & Gamble

[Stephen Mitschke]

Good clarification Jim. If I understand correctly, a "new" host need notsupport all old device software versions. It should support all deviceversions on ITK 4.01 or newer, and should not drop support for any oldversions it has supported in the past. The combination of these two mean itwill support its' own installed base, and devices purchased on new projects.Did I get your intent?Tom WallaceEmerson Process Management

[Stephen Mitschke]

Tom:Yes, you correctly understood my intent. Host suppliers should supportwhateverthe field device revision is when the host system is first released, andfromthen on support that field device revision and all later revisions.Since you asked for feedback, I want to give you mine on interoperability.Iwould like to see all host systems developed so that they operate completelyandfully using the DD and CFF files that are posted on the Foundation web site.Itwould seem that this would go a long way to true interoperability. Anexampleof how this is not happening: the Emerson web sites have DD's and CFF's forusewith DeltaV and non-DeltaV systems. In some cases, the CFF's on Emerson'swebsite are different than what is on the Foundation web site. I can tell youthatin some instances I have tried all of these readily-available CFF's (theremaybe two or three) and none have worked with my host system. I later find outthat there is a "special" CFF that works between the device and my specifichost.A question for the vendors and the Foundation: why can't you get togetherandjust have one DD/CFF file that works independent of what host system I amusing?(I thought that was the original concept). Is there something wrong withtheFoundation's specification, their testing, or is it something else?Thanks!Jim ReiznerProcter & Gamble

[Stephen Mitschke]

Interoperability and device upgrades - what a fun topic (couldn't resist).Let me throw a little fuel on this fire.Everyone seems to want backward compatibility for old field devices - exceptme. I don't think it is a practical idea and I think it is the wrong goal.The reason we had an interoperability improvement project is because wedidn't have good interoperability in the early days. There was a lot ofplug and pray instead of plug and play. There was a combination of missingspecifications, different interpretation of specifications, missing tests,and a lack of maturity that caused a lot of problems. The problems weresolvable, but took far too much expertise and effort for good economics. Sowe needed to tighten up the specifications and the testing. We did that.Before ITK 4, you had not only host to device interoperability problems, butdevice to device interoperability problems, and 3 way combination problemswhere any 2 would work okay but you couldn't mix them on a segment. Thenthere are the ones that will work but put a lot of errors on the bus anddrop off line for no reason at all.Given the current difficulty of doing upgrades in the field, I understandthe wish that we could just keep on using all of the old devices. However,I think you are doomed to continuing problems if you take that approach.The minute you swap out an old device with a new one on one of these legacysegments, you can have a whole range of problems outside of the device youjust changed. You will need to recheck the whole segment. There are realcompatibility problems between older field devices and current ones, and youcan't solve that with host trickery.Once you get your devices up to the ITK 4 level, a lot of thesecompatibility problems and maintenance headaches go away. I would recommendit highly.Now after all of that, what should we expect from downloading. Again, itdepends on how old your device is and what the manufacturer planned for.What I expect to see are devices with enough spare RAM that a complete newimage can be downloaded while the device is in operation- over a functioningsegment - from a standard DCS host. When downloading is complete, I expectan offline upgrade for transmitters with a simple recommissioning routine(Wizard) provided by the host. I want a completely on-line upgrade forvalves with negligible bump in control.I would like to run the download process as a background task from a host.It may take several minutes per device and I don't want people doing thisone at a time manually. However, I want the actual upgrade to be monitoredwith tools provided to make the monitoring easy.So, I don't want to run my plants forever with old buggy software in myfield devices. I want the latest and greatest software and I want toolsthat make it easy to maintain current software in field devices. Oh andyes, I am willing to pay for it.Herman StoreyShell Global Solutions, Automation Engineering (OGUS OGLA)

[Stephen Mitschke]

Hi Jim,Very good question!"Jim Reizner" wrote:> > A question for the vendors and the Foundation: why can't you get together> and> just have one DD/CFF file that works independent of what host system I am> using?> (I thought that was the original concept). Is there something wrong with> the> Foundation's specification, their testing, or is it something else?In interoperability testing (IT) all devices are subjected to the samestests on their DD and CFF files. Are these tests 100% complete? No.Nothing is 100%, especially where humans are concerned. We feel that wecover at least 98% of the DD capability and probably 95% of the CFFcapability. We have found a couple little used values in the CFF filethat need to be tested (one host vendor uses them).The FF is not getting much feedback from host vendors. Without knowingwhat is wrong, it is hard to fix it. Man to mechanic: "My car makes a noise."Mechanic (FF): "What does it sound like and where is the sound comingfrom?"Man: "The car just makes a noise"Mechanic: "Without knowing what the sound is and where it's coming from,I can't fix it..."Man: "Bummer"You get the idea... For the FF the have one universal DD/CFF, that allhosts can use, we need to know what changes/fixes the host vendors arerequesting from device vendors. But the vendors are not talking to us...Which leads me to believe that the changes are either syntax errors (theFF can't test these unless they are defined in the spec) or proprietaryinformation needed by the host.So how can we fix the issue? The FF needs feedback on what changes/fixesare being made. Once we know what the issues are, we can fix the specsor fix our test cases. But without knowing what the host vendors aredoing with the registered DD/CFF files, we can't fix it...-- Kurt ZechManager, Technical ServicesFieldbus Foundation

[Stephen Mitschke]

Dear All,I don't see why a host cannot work unless the devices are ITK4 now when ithas worked before. The changes to the actual protocol are minor. I thinkvendors are cautious but could possibly say that with ITK4 devices it willwork hassle free, with ITK3 devices it will work but may require sometweaking.Apart from dealing with ITK refinements, firmware upgrade is also good forother non-FF related enhancements such as improved temperature compensationand auto-calibration etc. Firmware upgrade is a very good thing, it's beenvery helpful to me. It is a good idea to have it included as part of astandard requirement for purchasing any Fieldbus device also including anynecessary tools.If the host computer supports Profiles (yes, FF got profiles too) thenmanaging versions of configurations becomes less difficult. Configurationsmade for one version can be moved to a device of another version withgreater ease.Tip: Build your control strategies as far as possible using Standard FFblocks using Enhanced or Custom blocks only when there really is no otherway. This way it becomes easier to migrate the control strategy acrossdifferent versions and even different device types and manufacturers in thefuture.If the host checks for consistency between the device configuration and theactual device, problems can be detected even before a download doomed tofail is attempted. We (Smar) recently improved with full consistency checkof device revision, DD revision, and including profile and profile revisionin Syscon 5.10.Tip: If the host does not support profile revisions try to first downloadjust a resource block to the device and then check the DD_REV and DEV_REVparameters in the actual device online. Based on this make the configurationselecting the proper file version. If the resource block does not downloadsuccessfully it may be that you are trying to download an ITK4 version intoan ITK3 version or vice versa.At the same time as the Fieldbus device population is growing manufacturerscome out with new device revisions all the time since the standard Fieldbusenables innovation, not stifle it. I even think there is a queue to get adevice registered so this may be one reason ITK4 re-registrations are a bitdelayed. As noticed by many, most manufacturers still provide the newerfiles on their own web site pending re-registration.Thus there can be a lag between the new devices and the files on the FF website or pre-installed on the host. What you need to do it get the matchingfile from the supplier's web site. Our tool only requires the three standardfiles from the device supplier so once a manufacturer makes a new deviceavailable you can use it straight away without waiting for any host-specificfiles.Hosts have different capabilities. A powerful feature in devices isdynamically instantiable function blocks. Meaning that you can within thememory limits of the device select any number of blocks, of any type from alibrary, any number of times. This allows very powerful control strategiesto be built and remain distributed. Not all devices and not all hostssupport this. Of the hosts that don't support it, some ignore it whileothers get confused unless they are loaded with a different non-instantiateversion of the capabilities file. Instantiation may be a feature you want toput into the already long requirements list for your host computer.Jonas BergeSmar Singapore

[Stephen Mitschke]

I have been watching with interest the various comments on upgrades, ITK 4.0and device download over the past few weeks. I would like to offer onevendor's perspective on some of the points that have been raised.Fieldbus Foundation Interoperability testing, as embodied in ITK 4.0 (andimproved upon in ITK 4.1), has advanced the state of interoperability. ITK4.0 in particular made giant strides over the earlier specification. We'regetting close, but it's not quite there yet. Host Systems, Field Devices,Device Description and CFF files, the ITK itself, and FF specifications areall still evolving and being debugged (which I consider normal). Thisdebugging is the result of the ongoing Interoperability testing beingcarried out simultaneously at various locations. Because of this ongoingdebug effort, many issues that have been discussed here are surfacing.When problems are found during testing, they are being reported back in theappropriate manner. We report specification interpretation issues and/orITK problems to FF using the AR process. We report specific device issuesdirectly to that device's vendor. It is incumbent on the device vendor, notthe host supplier, to communicate these corrections back to FF. Often,device description and CFF issues encountered are just spelling and typoerrors that are easily remedied.In some instances, either the device supplier or the host supplier havecreated unique CFF files for pre-ITK 4.0 devices to allow the devices tointeroperate with hosts having off line configuration capability. In somecases, even after creating these special CFF files, the device still doesnot work because of other incompatibilities. Some early, pre ITK 4.0devices, for example, were unsupportable because of inherent deviceproblems, including misimplemented (i.e., malfunctioning) control functions.The FF specifications and the Host Interoperability Test Suite each allowhost vendors to support various subsets of features. Different vendors (ofdevices and hosts alike) have supported different features depending onmarket interests. Because of this "subsetting," some device DDs have had tobe adapted to particular host systems. And with new capabilities beingproposed all the time, it is unlikely that every system and will ever "catchup." Of course, host systems will need to (and do) support multiplerevisions of devices as the devices mature. There is no getting around thisfact.Each vendor has had to make difficult choices about what to support. AtHoneywell, for example, we chose PlantScape R400 to require devices to beITK 4.0 or greater based on two premises:* As stated above, devices prior to ITK 4.0 had many serious issues. ITK4.0 forced a level of maturity below which we felt operation was notadvisable.* ITK 4.0 was the first to require the standardized CFF files needed foroffline configuration. Offline configuration capability was a marketrequirement of our users.For ease of upgrade and replacement, we developed a device code (firmware)download capability that is in our system and is now part of the FoundationFieldbus spec. This was intended to solve a lot of the issues that havebeen discussed here. Thus, as improved versions of device code becomeavailable, problems get fixed without the hassle of replacing electronics.We are glad to see that many other vendors following suit.John YingstFieldbus System Product ManagerHoneywell ACSPhoenix, Arizona

[Stephen Mitschke]

Ian, In addition there is also the issue of ON LINE upgrades. As far as I knowonly the Fisher DVC 6000 have the capability to do online firmware upgradesas the unit has more than 100% spare memory.To do online upgrades the device must be able to load the new firmware whilerunning on the old version, confirm that the new firmware is OK and thenswitch over. I believe FR is planning to upgrade all new releases to havemore than 100% spare memory.RegardsDeon F. RaeInstrumentation & Control Engineer>ChevronTexaco, ERTC, Process Automation

[Stephen Mitschke]

Two notes from Honeywell on this topic.Ian- - - - - -Honeywell (and Flowserve) FF devices have ALWAYS had this capability!! TheST3000 Pressure xmtr, ST350 Temperature xmtr and Flowserve Logix 1400 accepton-line code download. We developed this capability and donated the patent to FF. With somerequested modifications, this is the new standard.John YingstProduct ManagerHoneywellPhoenix, AZ- - - - - - note 2 - - - - - I just wanted to let you know that ST 3000, STT 3000 and the Logix valvecontroller have this capability now.Today, we have 100 % spare memory. We have 2 domains internally. One isused for operation, the second to receive the downloaded code.Therefore, Honeywell transmitters can have a new code downloaded whileoperating.Could you forward this to Deon, or provide Deon's e-mail so I could forward?Thanks.John SchnakeHoneywell

[Stephen Mitschke]

IanWe are developing on-line capability as well and we have some product already has. However, it is important that on-line update function will be installed into major field devices and download method from host instruments or tools as same manner.So, we have to accelerate FF one-line update standardization.Carl SonodaYokogawa