FF commissioning

Hi Everyone,

 

Someone just pointed to this whitepaper on this forum about Fast Device Configuration and Commissioning with AMS 12.5 and DeltaV: http://www2.emersonprocess.com/siteadmincenter/PM%20Asset%20Optimization%20Documents/ProductWhitePapers/amsdm_wp_FastDevConfCom.pdf.

As far as I can tell there are not so many new things, besides some Excel integration and bulk editing capability which should be interesting. Does anyone have experience with the method described in the whitepaper? Could you clarify the workflow a bit?

I can tell you how we are commissioning the instruments (DeltaV 12.3, AMS 12, 8 types of insturments from two instrument vendors, neither of them is Emerson):

Prerequisites:

  • autocommissioning is enabled with "device data is master" option
  • instruments are delivered with the correct tagname

Main steps:

  1. bulk edit the FF placeholders 
  2. connect the system to the controller
  3. commission the controller and download it
  4. autocommissioning starts and commissions the instruments (in background, the system is NOT blocked; takes 4-5 minutes per instrument)
  5. manually commission the instruments which did not autocommission (mostly because incorrect tag name; about 10% in our case)
  6. do an express fieldbus download (could take an hour for 50-100 instruments, system IS BLOCKED so we ususally start the download before lunch break or before leaving and let it run overnight)
  7. manually configure the instruments in AMS (on average about 5 parameters need to be changed per instrument, takes 2-3 minutes per instrument)

The procedure does not require device templates and reconciliation.

So I would say that we could commission 100 instruments by "working" on them for less than an hour, if 10% of them would not fail to autocommission. The whole process takes about 3 hours, but autocommissioning runs in the background and we try to do the download at a time where we do not block the workstation. Because of the 10%, add 1 hour.

As a twist: we have a master system from where we deliver the DeltaV config (including FF placeholders) to 5 mobile systems on which we do the commissioning. After commissioning is finished, we bring back the commissioned FF placeholders (in fact we bring back an fhx export of the controllers) and we also bring back the AMS audit trail (the mobile stations are set to Roving and we do a Remote to base export).

So, could anyone point out where this new method and device templates in general would come in handy in our particular case?

As a side question: what is actually the impact if, during manual commissioning I click the "Do not wait" button while the device is changing state or while it is uploading the parameters into the database? Does it act like an abort button or does it continue in the background? What if it fails in the background, will I get notified?

The issue I see with pre-configured placeholders is that for example autocommissioning with "placeholer is master" option is only supported for a couple of Emerson instruments (the whitepaper also only talks about them). Or has it been extended to more instruments recently?

Thank you for your opinions,

 

Istvan

10 Replies

  • Hi Everyone,

    In the meantime we upgraded to DeltaV 12.3.1 and AMS 12.5 so I had a chance to see the new Bulk Transfer Utility in AMS. So I can more or less answer my own question above.

    Basically even if we would have had AMS 12.5 during commissioning, this utility would have only been handy for point 7. We need to parametrize the instruments after commissioning, because they are not Emerson instruments, so they do not support "placeholder is master" during autocommissioning. This means that we would have needed to commission them exactly as I described in points 1-6 and then we could have parametrized them with the Bulk Transfer Utility. If our instruments would support "placeholder is master", we could parametrize them before even connecting them to the system, but this does not really speed things up.

    Because documentation is a bit scarce, let me summarize the Bulk Transfer Utility. It all boils down to an Excel table with two columns: template name and instrument name. You can then import this table to AMS and AMS applies defined parameters from the template to the instrument. It is quite smart, it takes the blocks out of service, and if you define the target modes in the template to be Automatic, it even puts them back to Auto. You can do this parametrization on a placeholder or on a live instrument, no difference. Audit trail entries are also quite nice.

    In any case, the new utility is a great improvement to speed up parametrization, it's only that in our particular case parametrization was anyway quite fast. Anyway, we will certainly use it for the couple of instruments which we did not yet commission/parametrize.

    What is still very much missing from AMS: a sort of bulk edit plugin to build the AMS database. For now, the only way to build the database is to drag the instruments one by one from the Physical Network to the Plant Database. This is a very time-consuming and boring task. I hope this will soon be automated.

    What is still missing from our workflow: after everything is done, we would like to double-check the parametrization. I am thinking of creating a huge generic export file from AMS (xml), bringing it into Excel and comparing each instrument with a template. Then for each deviation decide whether it should indeed match or is it OK if it doesn't (e.g. device tag, ranges, etc). I made a quick check and this xml, when imported to Excel, results in 1000-2000 lines per instrument. Does any of you have a good way to do this? The AMS built-in functionality or comparing the instruments to a template can only be done manually, one by one, there is no "bulk compare" as far as I know.

    I hope these "bulk" functionalities will be further developed in the next releases of AMS, there are quite big opportuinities to speed things up.

    Please share any ideas.

    Istvan

  • In reply to István Orbán:

    I see now that there is also a nice press release on the subject: www2.emersonprocess.com/.../1403-amssuitebulkcommissioning.aspx

  • In reply to István Orbán:

    Dear Istvan,

    AMS has great reporting utilities with QuickCheck and the Device Configuration reporting tool.

    Besides the Bulk Transfer Utility also a new reporting utility is introduced in AMS v12.5. As you state yourself. Without having a proper checking mechanism you never can prove parameters are correctly set in the device. The Device Configuration reporting tool is what you're looking for. No need to engineer a cumbersome and error prone workaround yourself based on historic data.

    The Device Reporting Tool uses the linking information to compare the download parameters in the Device Template with the actual parameters in the devices linked and generates two type of reports. One report is an overview of all the downloaded parameters of all linked devices indicating differences in red and the second shows only the differences. Important to know is that the reporting utility reads the parameter values from the actual device. It is not reading data stored in AMS.

    Currently the Bulk Transfer Utility and Device Configuration reporting tool works only for FF-devices. Reporting of binary data is not supported yet. Improvements and extension to support HART can be expected in one of the next versions.

    Another way to create reports is the use of QuickCheck. Quickcheck is a snap-on available for many years already. With QuickCheck you can define a report for a certain Device type and rev and make a selection of the parameters you want to read from the device(s) obeying the same device type and rev. You can create reports for HART and FF devices. And you can define the group of devices you want to show the parameters of in the report.

    With running a report (QuickCheck or the Device Configuration reporting tool) the parameters are read from the device. Keep in mind the generation of a report can take considerable time if you have a large number of devices in a report.

    We plan to use reports created by QuickCheck to be able to make selections of devices in report on. We don't want to scan all devices every time we have commissioned new devices. For comparison of Device Template data and actual device data we'll use spreadsheets.

    An easy way to move the device to the AMS plant database without having to find it in the physical network is by selecting 'open with AMS' in the device context menu in Delta Explore. The device is shown in the AMS tag search window and you can directly move it to the AMS plant database.

    Your ideas to improve engineering of AMS in an early stage in a project has been recognized (by me anyway). I agree with the need for importing the AMS plant database structure. But also to be able to configure or import the physical networks based on host configuration including device tag naming in an early project stage. Currently HART and FF devices are only visible within AMS once commissioned and that makes the AMS related tasks part the commissioning and thus critical and risky. Considerable time savings can be achieved if we could omit the AMS related tasks.

    Success,

    Rob Sosef.

  • In reply to Rob Sosef:

    Dear Rob,

    Thank you for the great insight. I made a quick test with QuickCheck and it seems to work fine. The disadvantage compared to the xml export is that you need to specify which parameters you want to export (also need to name the columns manually), but the BIG advantage is that it results in one line per instrument, not thousands Smile. Do you know whether there is a limit on the number of parameters we can export? Can we just grab (almost) all of them?

    I could not install the other tool, because it needs SQL Integration Services which we do not have on our test system (we are going to have it in the plant).

    As for building the database, our plan is to use Device Connection View and drag&drop from the right tree (physical network) to the left tree (plant database).

    Istvan

  • Hi Istvan,
     
    Building reports need some engineering and configuration. But once configured you can run it time after time.
     
    I never had issues with the number of parameters or the number of tags. There was never a need to check all parameters only a small subset. Depending on the purpose of a report specific data is retrieved. You could think of certain diagnostic parameters of a type of device you want to check every year.
     
    If the plan is to assign the devices after commissioning and not at the moment of commissioning you can certainly use your method. We see advantage assign the devices during commissioning because the device if healthy has to be assigned to the alert monitor as part of the commissioning procedure.
    Tag search window will be helpful to find not assigned (spare) devices or specific spare devices.
     
    Regards,
     
    Rob Sosef | +31704136830
     
     
     
    Click to show quoted text
    From: István Orbán [mailto:bounce-Istvan_Orban@community.emerson.com]
    Sent: Wednesday, August 06, 2014 05:22
    To: DeltaV@community.emerson.com
    Subject: RE: [EE365 DeltaV Track] FF commissioning
     

    Dear Rob,

    Thank you for the great insight. I made a quick test with QuickCheck and it seems to work fine. The disadvantage compared to the xml export is that you need to specify which parameters you want to export (also need to name the columns manually), but the BIG advantage is that it results in one line per instrument, not thousands Smile. Do you know whether there is a limit on the number of parameters we can export? Can we just grab (almost) all of them?

    I could not install the other tool, because it needs SQL Integration Services which we do not have on our test system (we are going to have it in the plant).

    As for building the database, our plan is to use Device Connection View and drag&drop from the right tree (physical network) to the left tree (plant database).

    Istvan

  • In reply to Rob Sosef:

    I found out about a better way to build the database: in Device Connection View, right-click a Control Module and Assign Spare Device. You get a list of all spare devices and you can select multiple devices and assign them to that control module. It really speeds up things in our case compared to dragging&dropping from Physical Network to Plant Database.

  • In reply to Rob Sosef:

    I see in KBA NK-1500-0005 that there is an update to XML exporting. Does anyone have any experience with it? I would like to fetch all the live parameters from all the instruments in an easily processable output file.
  • In reply to István Orbán:

    To answer my own question from 15 Jan: the XML export tool automates and simplifies the Generic Export process I mentioned in my post from 5 Aug 2014, so it gives the same huge XML. QuickCheck remains our solution to export the parameters.
  • In reply to István Orbán:

    Thanks for taking the time to revisit this topic and share your expertise with the community, .

    Best Regards,

    Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast

  • In reply to István Orbán:

    Another update on exporting the parameters from the devices: AMS now has a reporting tool, called AMS User Configuration Reports. You can see a screenshot here: www2.emersonprocess.com/.../amsdm_wp_FastDevConfCom.pdf