This has been around for a few years. We have a peculiar site with ten islanded Westinghouse (Emerson) WDPF systems running turbine-generators, all glued together with a Foxboro I/A system running BoP. You can understand why the Foxboro idea appealed to us, so naturally we did some digging in to this. Unfortunately Foxboro didn't (at that time) offer the specialised I/O for our application, only the basic analog in & out and digital in & out which made it a non-starter for us. Foxboro's turbo-generator application expertise didn't full us with any confidence either at the time.
Emerson are at it too - they've released a controller-level replacement for the older Bailey system which preserves the Bailey I/O, and I expect that other vendors are on the target list. Rumour out of Pittsburgh is that Foxboro's I/A is next.
It's an interesting idea but one with massive caveats, especially for those plants with complex application software.
----------------------------------
If we learn from our mistakes I'm getting a great education!
Having been involved with reverse engineering old DCS's (and even a PDP11 based 'home made' system) with the objective of 'translating' these existing applications to modern DCS's I feel qualified to comment.
Interfacing to existing wiring (by compatible hardware plug-in's) or to the IO network is not difficult - it is deterministic. Hardware can be designed to fit the existing equipment and if there are enough to be replace it is worth it.
Application software is completely different and is likely to be by far the most expensive thing to replace. Programming paradigms have moved on, old DCS systems are closed and most importantly each is programmed a bit differently.
This becomes very apparent with batch or with systems that have any sequencing and logic handling, and even for loops and their interconnections it is extremely difficult to translate from old software to new.
Several manufacturers can provide a virtual I/O connection for third-party I/O. Then they can offer system migration to leave the I/O and wiring in-place; replacing only the DCS control and network communications hardware. This provides the "foot-in-the-door" leaving the client with obsolete I/O that is likely near the end of the product life cycle. Thus, as spare or replacement I/O becomes unavailable the plant must migrate the balance to the new system. Perhaps this is acceptable as a short-term patch. I would prefer a complete system replacement over this patchwork process. Also, the initial sale may include deep discount. Once the control and network hardware and software are in-place the subsequent expansions to replace the I/O may be closer to list price.
Looking at the Invensys link they say
"We simply manufacture our I/O modules as form-fit, one-for-one replacements for the I/O of your mainstream systems "
So this is Not interfacing to existing I/O, it is new I/O that fits existing slots. Which is not quite what ScottyUK and JLSeagull have described, and not something that I am aware that other DCS supplier do.
Nonetheless their comments are still mostly relevant.
Yes, it is two different approaches and JLSeagull highlights the big problem with what Emerson are proposing. That plus I could foresee the vendor whose system has been partially replaced being somewhat tardy when it comes to supplying spares, especially as stocks dry up.
The problem with Foxboro's proposal is that legacy I/O, certainly in the Westinghouse case, is rather lavish with the amount of space occupied by relatively few channels and does nothing to address this. A replacement with the modern equivalent - Foxboro's 200 Series or Emerson's R-Line - would give perhaps four times the density, something which is highly significant in a plant which was almost big enough for the equipment it contained when it was originally built.
I am still positive that the application software migration is a far larger problem than I/O replacement.
----------------------------------
If we learn from our mistakes I'm getting a great education!
The vendors also mention their automated configuration tools. These may be good for new projects or simple PID applications. However, an existing plant may have lots of little wrinkles configured. Consider documenting and reviewing each loop before considering the automated tools.
