[foxboro] Automation of upload/checkpoint/save_all at sites with IACC

After Tom Vandewater's question on automating uploads, checkpoints, and
save_alls using IACC was met with stony silence, I'm assuming it can't
be done.  This is not an acceptable situation in my opinion, since these
tasks need to be part of a sensible backup strategy.  Simply backing up
the IACC database without doing regular uploads is not a good strategy,
since many important parameters, such as tuning and alarm settings, can
and will be modified via the detail displays or other displays, and
these changes need to be recorded and saved in a regular backup file.
Apparently, the only way to do uploads with IACC is to click on a button
using the GUI, and then wait 3 to 4 hours while the upload occurs, with
IACC being unavailable the whole time.  This is not practical when you
have 20 or 30 or more CP's to upload.
 

Given this state of affairs, I'd like to propose a backup regime that,
while not being ideal, at least accomplishes the task of providing a
regular unattended save_all backup with uploads that can be used in case
of emergency.  I'd like all of you out there to poke holes in this and
tell me why this wouldn't work, or even better, how to make it work.

 

First of all, you would use the save_all.sh script at
TheCassandraProject.org  that has been tried and tested on systems with
ICC for years.  It would run on weekends or late at night, as it is
typically set up to do, using either crontab of Windows Task Scheduler.
I know that it says specifically NOT to use it on IACC systems in the
manual, but I don't see why it wouldn't work.  Even with IACC present,
you can still do uploads, checkpoints, and save_alls using iccdrvr.tsk.
I just tested it today, and it works fine.  The caveat is that you can't
have someone using IACC while you do that, which if you schedule the job
to run in the middle of the night or on a weekend, the chances of that
are slim.

 

Using save_all.sh will do the normal upload, checkpoint, and save_all
(and optional shrink) of the CP database, like we've all been doing
since the beginning of I/A time.

 

Of course, IACC will know nothing about any of this, and as far as I can
tell, does not need to.  The purpose of the upload/checkpoint/save_all
is to create an "emergency" copy of the CP database, updated with all
the latest information.  You would only use it if your CP was
irretrievably hosed, and you had to initialize and re-load it, or you
lost the host hard drive along with the checkpoint and work files.  You
would never, ever use it for anything else.

 

IACC has its own database or databases (which you would backup
separately).  This database has all the parameters available for you to
edit, but you generally do not use IACC to edit things like tuning
parameters, and if you do, you will overwrite the current value when you
download anyway.  More typically, you use IACC to modify block
connections or CALCA block steps or add and delete blocks.  None of
these things are affected by the upload process.  As soon as you
download IACC changes, they become part of the workfile and are
immediately checkpointed, but they don't affect other parameters that
were not changed.

 

As you go along, week by week, doing automated uploads and save_alls,
the IACC database will become increasingly different from the CP because
of the upload process, but I don't really see how this is a problem,
since the only things that will be different will be things you
typically don't change using IACC anyway.

 

If in the event of a catastrophic CP failure, you would use your
uploaded save_all file created by save_all.sh as the load_all to the
failed CP.  After you finished loading the CP, you would go into IACC
and do a "Compare to CP".  This process would identify any differences
and allow you update the IACC database with those differences.

 

If the hard drive failed, you would take your backup copy hard drive
image that you created using Symantec Backup Exec Save and Restore (or
something similar) and re-create the image.  This re-created image would
include, presumably, the latest save_alls you created using save_all.sh,
as well the IACC database(s), and really nothing will have changed,
since the CP will continue to be cranking along using its current image.
You'd lose any changes since the last backup, but that's what happens in
that scenario no matter what you do.  And of course, you still can't
recreate your workfile from the running CP image, after decades of
asking for that feature, and having IACC or ICC won't make any
difference.

 

If the CP double-reboots for some reason and needs to reload its
checkpoint file, at least this way you have an uploaded version of the
checkpoint file.  If you went the IACC GUI-only route and never bothered
to upload because it can't be automated and takes too long, you'd be
stuck with a non-uploaded checkpoint file that doesn't have any new
tuning parameters, setpoint changes, or alarm settings, etc.

 

I know there a million scenarios that need to be considered, and that's
why I'm putting this forth as a proposal to be shot down.  Here's one:
What if you add a block with IACC, download it to the CP, and then the
CP crashes and you have to rebuild it?  Can you take the old save_all
you did last night and do a load_all, and reconcile it with IACC using
Compare to CP, or will you get some kind of crazy error because IACC has
a block that the CP doesn't have?   How about if you DELETE a block
using IACC, and the CP crashes?  Can you take your day-old save_all, do
a load_all, and reconcile with IACC, or will IACC say that block you
deleted is still on the CP and you can't get rid of it?  I don't know
the answers, but I'd like to find out.

 

Tim Lowell

Control Systems Engineer

Tesoro Petroleum Company

210-283-2929 (w)

210-253-0225 (c)

tlowell@xxxxxxxxxxx

 


 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: