We are moving from an IA 8.6 host to an IA 8.8 host (to allow us to move to
a virtualised V90 platform). Our galaxy will therefore have to be upgraded
from FCS3.0 to version 4.0 or above. We have recently performed a galaxy
migration from FCS4.0 to Control Software 6.0 for our OTS system, and
following the upgrade path 3.0 -> 4.0 -> 5.0 -> 6.0, we found that during
the 4.0 -> 5.0 database upgrade there were errors each time we tried.
To get around these errors in the live plant system, we are thinking of
bypassing the upgrade path by performing the following:
On FCS3.0 galaxy:
Step 1: Remove all undeployed blocks,
Step 2: upload runtime changes,
Step 3: checkpoint,
Step 4: Export Objects (on a per CP basis).
On newly installed Control Software 6.0 galaxy:
Step 5: Import objects,
Step 6: assign to correct Equipment Unit,
Step 7: Import objects again (originally it imports to unassigned and
therefore the IOM_ID references are all lost, the second import fills all
that back in),
Step 8: use synchronise deploy status to mark everything as âdeployedâ.
Step 9: Upload runtime changes again
Has anyone got any experience with the above process and can think of a
reason why it would not be a good idea to perform. Our alternative option
is to just install FCS4.0 as the new galaxy by performing an upgrade to the
FCS3.0 galaxy. (We prefer the 6.0 option so that we can get the live plant
to the same version of the OTS).
Thanks for any insight you can provide,
Aaron Boshammer
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
