Hi! Anybody help us on the list of Bailey Infi90 system limitations? we need to come up with a list of Bailey Infi90 system limitations from technical points (not commercial) for migration justification.

Limitations such as; Communication speed, CPU Memory, PID control, ACP etc...

Thanks in advance..

With Regards,
Harsha

 

Could you describe your current system? that might help a little.

 

>Could you describe your current system? that might help a little.

The existing Bailey ifi90 has the complete redundent configuration; (NW, PCU, PS)
the modules on the rack shows;
INNIS01
INNPM01
INNIS01
INNPM01
IMMFP12
IMMFP12
IMFBS01
IMFBS01
IMDS102
IMDSO04
INICT01
with IEPAS02 etc....

The Console type is OIS42,

Hope this information will help..

Regards,
harsha

 

Wow, you have a very old INFI90 system. There have been new enhancements in the communication system and in the speed/capacity of the controllers. Also I can see you still use the old OIS42's which are based in obsolete DEC computers. You can justify an upgrade based in just obsolescence and availability of the hardware which I think is no longer being supplied by ABB(who now owns the Bailey techonology) or DEC (which was bought by Compaq which also was acquired by HP). Critical issues, the way I see it, are the console system and the old power supply system. Next critical issues are controllers and the communication system (NIS/NPM based). So you may think in an upgrade plan replacing first the consoles and the power supply system (which may be replaced by ABB's new MPSIII), and then go for the replacement of the controllers and comm system.

You may choose to go with ABB and migrate your system to a new 800xa system which may use most of the existing application. Also you may consider to go to a different system from a different supplier and reengineer the whole application which might be costly.

 

I have exactly the same control system in my plant. Last year we upgraded to MPS3 power supply as the old power supply unit is very costly in terms of spares and unreliable during thunderstorm season. As for the OIS, nothing much were able to be done except for the replacement of the old crt to lcd screens. As a backup, PGP from ABB were installed in case all 4 ois fail at the same time. Now i have 1 OIS down which I need to replace the CPU (thx god I still have 1 new left )during the outage next month.

 

I know this is a thread revival but I was told by an ABB rep that they will be providing support until 2025. So you need to talk to your local rep to get an upgrade path if you want to stick with your infi-90.

 

ABB formally announced a few years ago that the Harmony/Infi90 system will remain in the "active" phase through at least 2015, transitioning to the "classic" phase through at least 2025, and finally transitioning to the "obsolete" phase. I have also read that ABB attempts to have a minimum classic and obsolete phase duration of at least 7 years. That puts us to 2032 if my math is right.

My understanding of the phases, based on reading and discussions with ABB personnel (not just sales and marketing...) is this:

Active - Fully available including large new complete engineered systems. Ongoing training classes available. R&D monies allocated for new stuff.

Classic - Fully available to maintain and expand existing systems. R&D not spent to add more capabilities, but limited to allow for new parts to be available. This would include development of engineering software applications to run on current computer operating systems.

Obsolete - New modules available as supplier sub component parts are available. Repair/refurbishment when not. No R&D.

Keep in mind that while a system is "active" or "classic", components, such as an MFP12, can be made "obsolete" due to supplier parts availability. However, there is generally a pretty clean direct replacement (BRC300 or 400 in the MFP case.) I know that some items, like Block IO, are not a simple plug and play replacement. The OIS path is also complex. But my experience-based observation is that they have done as good or better than other suppliers in this regard. Again, these are my experienced based observations as a customer.

So, enough advertisement and back to the thread.

Is your MFP12/OIS42 system "old school" as my son would say, or are you running at a huge risk? I would say no based on the discussion above.

Are you in the position to evaluate your options and create/update a 5 and 10 year plan? Obviously so due to your questions.

However, the original line of questioning ("tell me what the CPU memory specifications are on my Infi90 system so I can justify a new one") is quite ridiculous. That may sound harsh, but I'm trying to save your career. Let's face it - every day there is something better. To go before management of a company and tell them that we need a new one because the old one is old is asking for trouble, in most organizations anyway.

Consider this question. The Infi90 has X memory, Y speed, etc. It worked when it was installed, and it works today. Are you saying that it won't work tomorrow because of X and Y? That makes no logical sense.

What is your real fear? What are your real issues? Write them down, think about them. Ask others on this forum. Then ask the OEM what they can do for you. But consider a 5 and 10 year plan. Then talk to other suppliers and see what they can do for you. At that point you will be informed, and in turn make an informed recommendation to your company.

Not that you are doing this...but it amazes me when someone rips and replaces an Infi90 system when a simple power supply/controller/HMI upgrade (at say 20% of the rip and replace cost) can get them another 15 years of operation. Another variation of a bad decision is to put in a brand X HMI on a Harmony/Infi90 without having the rest of the plan in place. Note that I did not say that putting in a 3rd party HMI is bad. If you put in a brand X HMI, and save $100,000 when compared to ABB (just to pull a number out of the air) that is ok. But if 5 years later you give brand X a no-bid contract to replace all of the controls you have just lost your savings times 10 or more. That is really bad. Think things all of the way through.

What if ABB could, over time to levelize your cash flow if needed, convert one or two controllers at a time from Harmony to 800xA, retaining your Harmony IO. That means that you don't rework any IO, any field cables, any associated drawings, not to mention lost production. What if they could take the Harmony logic drawings and convert that proven control strategy to the new controller such that you don't even need to tune. What is the cost difference to a rip and replace?

If you go that route, it would behoove you to get the ABB costs up front before you commit. The natural behavior of any supplier will be to take some advantage of any possible situation.

 

Good day,... apologies for hijacking this thread. I need some help from Bailey INFI 90 experts. I need to know if I can achieve modbus communication from another system to the Bailey INFI 90 system. What will be required on the INFI 90 side?

 

You have options:

1. Set up an MFC/MFP/BRC (controller) as a Foreign Device Interface (FDI) running with a Modbus master application. The controller will require a termination unit with serial ports. Both RS232 and RS485 are available in this configuration, although if you want redundant ports RS232 is the only option. Redundancy at the controller level is optional as well. The Modbus mapping ends up running in an "NBS" file, executing in the same controller with a traditional "CFG" files. Within the CFG file are function blocks that expose the Modbus reads to individual block numbers. You can write from any block number.

2. If you don't mind the "Microsoft factor" or increased security issues (real or perceived) you can use one of many OPC applications (third party and ABB) that can read/write to the system via an ICT. You will also need one of the many available OPC Modbus drivers and connect the two. Of course this type of interface is open to many additional protocols, not just Modbus.

3. As a variation to item 2, if you have a Process Portal A based HMI on top of the Infi90, this is based on OPC so some of the software mentioned in item 2 is already in place. If the purpose of the interface includes presenting unaltered data on the HMI, you can go direct and bypass the property transfer into the Infi90 controller world. You can, if needed, send a subset of tags to Infi90 and the remainder/all to the HMI.

There are pros and cons to each approach. I highly recommend having a technical discussion with ABB. There are some pretty new (<1 yr) products that they have introduced in this space that I have not used yet (I've got all three mentioned above.) Look at all your options before deciding.

John

 

This is easily accomplished by using a Modbus OPC server and Infi 90 OPC server with bridging software to link the two OPC servers together. The RoviSys OPC90 Server and BridgeMaster software products can be used for the INFI 90 side.

 

Item 2 can be easily tried using evaluation products. As pointed out you will need a modbus OPC server (Kepware has a few of these), Infi 90 OPC server and bridging software to link the two servers together (RoviSys Infi 90 OPC server and BridgeMaster products can be evaluated at no cost).

 

Just to reassure Harsha and to add weight to John's comments regarding the various phases from 'active' to obsolete etc., you can simply browse this entire site and look for posts about Bailey Infi90 / ABB Harmony and after a while, one thing will become apparent: You will notice that there is relatively very little posted about these systems! This should tell you something...

Not that I am biased of course ...

I've been working with these systems for about 27 years now, since the very early Network 90 and its classic NOIU01 / 02 console, right up to the present, with the 800 xa series and am currently engaged at a power station that uses 'classic' Infi90 (that's INNIS01 INNIS11 / INNPM01/11 and IMMFP02/12 controllers and Symphony power system). We have an ABB (Italy) Power Generation Portal (PGP v 3.2) HMI, which was chosen over PPB or CNT or other HMI products simply because it was the only console available that could use the SODG displays that were used on the former OIS43 consoles. (We still have one of those in service, but is only used as the time synch master and for a backup if the entire PGP has to be taken off line).

I have worked with other DCS products and a number of 'generic' HMI's and still maintain that nothing even comes close to the Bailey / ABB systems in terms of their ability to be easily upgraded - backward compatibility and support of what would otherwise be very 'old' system components. The actual DCS hardware is VERY reliable and I've worked with systems that have been 'online' continuously for more than 20 years without a single glitch over that period!

From what you've said about your system (and to back up John's comments), you really only need to concern yourself at this stage with the HMI's and maybe the cabinet power systems, the rest of it should keep your plant running for many more years yet!

Since you are upgrading OIS4xx consoles, you should consider the PGP as a replacement as the SODG displays from your OIS42 will go straight into this console with minor tidying up required. Any other HMI will require the graphics to be built 'from scratch' again and if your system is a large one (such as ours with over 2000 displays), that could mean months even YEARS of extra work!

 

Refer to John's post (25 Jan 2011) and of all three options he outlines, I've found the first one to be the simplest and most reliable. Depending on what Infi90 'tools' you have on hand, you can use a simple DOS program known as GPI02 or the more up-to-date version of it that partners with the 'Composer' Toolset, which is what appears to be the FDI John is talking about. (If you are using the old 'Wintools' or even older SCAD you must use the GPI02, which partners with the .cfg file produced by those.

In both cases a .NBS file is downloaded together with the normal .cfg file to the module running the interface.

I have also worked with OPC interfaces on Conductor NT and although it works OK, you will also need a third party OPC server to connect to the ABB OPC database.

I cannot comment on the OPC with PPB as I haven't worked with OPC on that type of console, however of the two I have used, the GPI02 or FDI which runs a .NBS (a C language simple script that connects your foreign device to special Bailey function codes via an RS232 link) is BY FAR the more reliable of the two options.

Note that the .NBS file can only be saved in your Composer or Wintools project and downloaded (say in the event the module failed and you don't have redundant pair); it cannot be opened and edited. You can only edit the actual script with the GPI02 program or the FDI, then when you download it together with the module configuration (the function codes); the updated .NBS file is then replaced in the module.

ABB would no doubt have a few more options available now, so as John has suggested: you would be well advised to discuss it with them first.

 

In response to Anthony Porter:

> I cannot comment on the OPC with PPB as I haven't worked with OPC on that type of console

I worked at a site that had multiple ABB OPC servers set up to allow communication between DeltaV controllers and ABB PPB and it worked fine. I also set up a couple of OPC servers to allow communication to Matrikon's Alarm Manager and Control Performance Monitor. It is very easy to install but setting up DCOM will do your head in. It's a nightmare to set up if you don't have all servers on the same domain, but you can make it work (I suggest using OPC Tunneler from Matrikon)

--
Chris Jennings

 

Seems you are closely involved in the Harmony system. Maybe you can tell me: how does the recent launch and promotion of "Symphony Plus" fit into this ABB strategy? What is new about this? Is it still Bailey?

 

Symphony Plus (S+) is simply the next moniker in the Bailey Net90-Infi90-Symphony/Harmony naming scheme. As with all name changes there are some commensurate new products released, and this time around is no different in that regard. However, anyone that has this DCS "line" should realize that this new investment brings our trusted friend back for many years to come. The previously promised 2015 transfer from active to classic with support to 2025 is now indefinite. I suppose that promise was broken in a good way. Thus one can argue that this is the most important name change yet (realizing of course that the name is just skin deep, the real importance is the investment and continued commitment.)

As to the pieces and parts, starting at the HMI level, S+ adds "S+ Operations" (PGP - Power Generation Portal) as an alternative to the 800xA based PPA system. Both are available. As with any decision, there are pros and cons to both.

Moving to communications, the current NIS/NPM remain, but new models released over the last 2 years or so have significant capability improvements. But as is often the case ABB does a best in class job of letting you replace such things in pairs as long as firmware throughout the loop is at an appropriate level. For those that are running out of parts of old parts, if they become unobtainable, this is a good way to kick some free one pair at a time if you can't fund a wholesale upgrade.

There is a new processor with S+, the BRC410 I believe, with a built in Ethernet port. The initial function is for Modbus, but it does provide an open door for more, N'est-ce pas? I wonder what else they can do with that port... Moving from MFC/MFP or older BRC's to the current can be done in pairs like discussed above.

For interfaces to computers, the IET800 is the long awaited Ethernet CIU.

At the IO level, rack IO (all models I think are now upgraded to surface mount) are still available and viable, as well as S800 IO.

At the power supply level, the MPSIII is current.

Composer 5.1 is the new release with S+, and I believe is Windows 7 32 bit compatible.

As you can see I'm pretty darn happy with our stuff, some installed in 1983 and the latest installed in 2008, and some to be installed soon.

It's pretty cool to have a cabinet with many 1983 based rack IO modules, a 1997 MPSII power supply, some 1999 MFP02's, some BRCs, remote S800 IO, on Composer 5.0 and a PPA HMI, all circa 2007.

Here are some links to some official info:

http://www.abb.com/product/us/9AAC172067.aspx?country=US

http://www.abb.com/cawp/seitp202/a223fcb054afb121c125788e0047e181.aspx

 

Thanks a lot!

"S+ Operations" seems to me the greatest novelty though? What are the pros and cons you mention? What about 800xA in power? I thought they wanted to migrate all?

 

> "S+ Operations" seems to me the
> greatest novelty though? What are the
> pros and cons you mention?

Since S+ Operations (aka PGP) is new to me, I have not done any detailed comparison. My understanding is that ABB needed a lower cost HMI solution (compared to the 800xA PPA HMI) for Harmony applications, and this could help in that regard, even with the PPA system projects reaching a pretty good level of optimization and loaded on hardware now being deployed in a significantly smaller footprint by means of using virtual servers. If I were to do such a comparison, I would visit sites to compare features of both systems along with end user satisfaction. Another concern for me is that a lower cost solution often means less of the good stuff that I am used to (but that does not have to be the case).

From a technical standpoint, my understanding is that the S+ Operations is close to the OIS architecture, with each computer (Windows based) capable of acting as a server with its own ICT's. One of the pros is reliability when you have multiple independent servers. One of the cons is keeping the databases and files synchronized between them. The PPA Harmony Connect uses pretty much the same interface computer software (SQL server based database) as Process Portal B and Conductor NT from what I hear. One of the pros here is one database and one set of files to manage. One of the cons is that many feel that the system is "too complex".

>What about 800xA in power? I thought they wanted to migrate all?

What we want and what we get are often not in alignment, and ABB has lost a lot of HMI business to "third parties". Having attended the recent Automation and Power World conference in April, I can say that there is no shortage of 800xA PPA HMI's on top of Harmony systems in Power and other industries. However, there may be as many or more that have gone another direction. More than likely, for the systems that have not yet done an HMI upgrade, S+ Operations will provide ABB another tool to retain a higher percentage of their installed base than with PPA alone. Those two HMI options coupled with the fact that the controls hardware (processors, communications, IO's) are NOT obsolete (in spite of some of the innuendo from others) means that customers can avoid the "rip and replace" method of upgrades.

For those that start small with a third party HMI upgrade, thinking that they are saving money, tend to not think 5 to 10 years down the road when they (or their successor) hands a blank check to someone to finish the job and replace the PCU cabinets that they are convinced are obsolete. Such a waste. I suppose that company executives and boards of directors are not the only ones subject to a "quarter mentality".

 

In case it could be interesting someone... we have developed applications allowing ABB legacy consoles migration to the new 800xA (VB and PG2 new graphic builder). The migration is 100% guaranteed error free and can be done ON-LINE. We support all legacy consoles versions for MCS, OIS, PCV, CONDUCTOR and PPB. Every dynamic symbols and graphic are perfectly replicated. The migration include taglist, alarm management and historical trend replication. Additional options such as operator keyboard, advanced Harmony popup, Navigation Display Panels, and improved 3D replication is also available.

We have many successful major systems completed in North/South America, Europe and Asia...

Contact us if you want more details...
[email protected]

 

I need a little bit guidance regarding saving .NBS file from IMMFP01 using composer.

Can you please tell me how can I save .NBS file from IMMFP01 on composer? What options of Composer should I use to do so?

Hope you would help me.

Looking forward for your swift response.

Regards
Evil Genius