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:
Main steps:
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
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.
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
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 . 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).
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.
Best Regards,
Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast