GE Mark VI: Alarms and TRE files

K

Thread Starter

Kevin

Hello,

I have previously started a thread here about a year ago on the Mark VI and would first like to say thanks to all those who replied and assisted me then, it was a great help! I now want to gather input from the Mark VI community here regarding TRE files and configuration.

Has anyone here ever used TRE files and directly modified them, then imported them into their controller files to update their system? Particularly, Function TRE files and/or specific to alarm configuration.

Thanks!
 
Kevin,

It's been done with mixed results. It's not common, and--as always--good backups are extremely important. It's usually done by factory requisition engineers and sometimes shipped to the field--but it's not the preferred method of making modifications. One needs to be absolutely certain they have the proper .m6b files and card revision information and firmware and runtime. I can understand how it might be tempting if a lot of tedious, "simple" editing modifications need to be made--but caution is always advised.

You might try making the mod's in Toolbox, exporting the .tre files, then--starting from the same .m6b file, exporting to .tre files, editing the .tre files, the importing them, validating and building, then exporting to .tre files and comparing the "finished" .tre files and .m6b files to see if it all ends up being the same. It would be a lot of work, and maybe only necessary once--if it worked perfectly. Perhaps you could do it in chunks, making comparisons to check your work as you go. Might find minor errors in small groups, or, you might find it doesn't work well with the kind of changes you are making.

In any, case, good backups are critical!

Let us know how you fare!
 
Thanks CSA for your prompt response!

To give a little background, I had to update over 10,000 alarms for a combined cycle plant. Tedious was definitely on mind, but at the same time I wanted to ensure all the appropriate changes would be made without human error. I wrote a collection of scripts that would modify the TRE files and later verify the changes against a difference report between the unedited m6b's and the updated m6b's, which would then report any unauthorized changes. I found there were no unaccounted modifications via the difference report. I also did several spot checks to ensure the needed changes stuck and nothing appeared out of place. This was all done on a VMWare image and not on the actual plant EWS.

My concern was mainly whether the controllers will take the downloads without error, possibly due to some bug in the software, so I wanted to see if it had been done. Of course I plan on taking backups of the system as I always do when integrating new changes into the DCS, but considering the bulk of alarms that are involved I rather not stand empty handed to the customer because this is simply not work that could be done onsite in a timely manner.

Relevant to the matter, I also noticed that the alarm IDs shifted after importing the TRE files into the m6b's. Am I correct in saying that the alarm IDs are important for communication between the controllers and the alarm server? I know when you pack alarms, you need to do a "Put into Database" from Toolbox and a "Get from Database" on all CIMPLICITY workstations, so alarm IDs seem important for the function of the alarm system. I feel as if I need to perform this procedure as well since the alarm IDs shifted. I appreciate any and all input!
 
Kevin,

I believe the original intent of the .tre files was to allow modifications like you have described, and even more involved modifications without the need to have a person sit in front of a computer with Toolbox to make them. However, as is the case with many such "features" (on lots of programs/applications) the development work and the vetting of the results was never fully completed. So, the capability is there, but the results might not always be what's expected.

As for changing Alarm IDs, all I can say is that the Mark VI dynamically assigns memory locations to tags/points. I can also say that I believe if they change you would need to update the SDB and all "projects" (Toolbox projects and CIMPLICITY projects) to know about the new assignations in order to get the proper alarm information to display properly. But, that's just my SWAG on this question.

Hopefully MIKEVI can add to this and provide more detailed guidance.
 
Kevin,

As CSA has discussed the original intent of the .tre files was a way to export the .m6b files to perform a toolbox upgrade. These .tre files can be opened in toolbox or just with a standard text editor. The files were also a very nice way to perform one change that could be applied to a multiple unit site. I have not ever written any script or batch files to manipulate the .tre files, only done editing in a text editor or in toolbox. For a CC plant with over 10k alarms you must be working on one of the few ICS sites out there.
If you are modifying the .tre files and they import and validate in toolbox then you should be fine. As you mentioned you will need to perform a full put to the database since an import of the .tre files will reassign alarm signal tokens.

Assuming you back up the contents of the master folder and the SDB folder you should be covered for a backup if needed. Depending on the version of toolbox you are using it should flag this as a major difference and force an offline download. If for some reason it does not I would not allow it to try an online download. As mentioned then you will need to rebuild the .hmb files for all HMI's and update the Cimplicity project. As you know what you are doing is not rocket science, but the scale of what you are doing is much larger than most sites have to deal with. Best of luck and let us know how you proceed. I really miss the text files of Toolbox classic, I have not found the flexibility to modify projects with the new ToolboxST .xml files.
 
Thank you CSA and MIKEVI for your responses. I greatly appreciate the reassurance on the use of the .tre files. I didn't think it would present issues, but a comment from one of the customer's personnel led me to double think, especially since this is the first time I've done a configuration like this. Over 10k is definitely a lot, which we intend to bring down to a manageable level according to the ISA 18.2 standard.

I will follow all your suggestions and especially find the idea of backing up the SDB to be a good idea that I did not consider before. I have just a couple things I want to check by either/both of you since I have limited experience with CIMPLICITY.

Firstly, I intend on introducing new alarm classes into the system. I don't have a working copy of CIMPLICITY I could play with, but from what I read from the manual in page 18-2 (http://platforma.astor.com.pl/files/getfile/id/4664) it is done within CIMPLICITY Workbench itself. Therefore, once I add the alarm classes as such, I should immediately perform a configuration update, correct? This is important, because of these new alarm classes, I needed to force the existence of these alarm classes within the .m6b projects via an edit to the System Data .tre file in order to correctly re-prioritize a portion of the alarms to these specific alarm classes. I would hate to later perform a get on these .m6b files and find the added alarm classes disappear and potentially cause issues with the re-prioritized alarms. So does it make sense to make the change in CIMPLICITY and do the configuration update before proceeding with the put, get, build on the .m6b and .hmb files?
 
Top