| Author |
Topic: RBI Software |
 |
Shannon Riley |
Posted: 13-Feb-08 14:40 |
|
|
|
We're currently in the process of implementing RBI. I was wondering if anyone had any comments about software likes/dislikes. Have you switched between software programs at any time? API to Capstone or Meridium for example. Also any advice on archiving historical data when switching from a conventional time base inspection program to RBI.
Thanks,
Shannon Riley, RBI Project Engineer - Suncor Energy |
| |
|
admin |
Posted: 15-Dec-08 22:15 |
|
|
|
Shannon,
I have been involved in numerous "switching" exercises. Softwares with closed database architectures make it hard to switch the other way but you can ask for them to supply such a format for switching. You also need to know the level of detail and nomenclature required by the various DBs. DBs fields have specific requirements, that when they are not satisfied can cause the DB to "bomb out". Not a good thing. YOu should define up front what data is directly transferrable and what is not. Keep this in mind, there are a few qualitative RBI programs in the market masquerading as quantitative RBi programs, requiring the same level of effort to load and few of the advantages of output. When these rules are followed and points considered switching can be most straightforward.
Most importantly, use a technology you trust technically. In Alberta, as in many other jurisdictions, use a technology that is documented that you can review and show regulators. In Alberta it is the regulators option to require users of RBI to duplicate the software answer long hand from the technical basis. Think about it. I have also seen where many tools' final answer is not much more advantageous, than using conventional 510 and 570 rules producing incremental improvement at best. They just throw in the matrices and call it RBI. users should validate this.
Sadly there are many technologies that do not make the technical basis available. They often say, "We comply with API RP 580," and people confuse this with API RP 581, which is a documented technology. 580 is not a technology it is a set of minium recommendations for implementing, maintaining and updating an RBI program. It gives some guidance on what to look for in a software but offers no details.
Just as sadly, or maybe even more so, some software providers allude to having the same technical basis as API RP 581 (fyi API 581 is no longer just a base Resource Document, it is now an RP) and they do not. Not all but many are using a tremendous amount of poetic license when they say this. They will also claim that they cannot supply this because it is proprietary. This does not make sense. If it is the same as API 581 why does it need to be proprietary? API RP 581 is published in the public domain. I know because I have often been asked to review those non-API RBI software packages because users are reporting that they are not getting the same answers from the software as using the calculations and algorithms in 581. If one is not using the only API branded RBI Software, i.e. API RBI Software, the software provider should be providing licensees with the technical basis for their software for them to review to see if it is representative of recognized and gererally accepted good engineering practices, as the owner operator is ultimately responsible.
Some also will not show the technical basis, say it is the same as 581, and they do not prove it by long hand calcuation from 581 with same input data to software for all areas, supply a risk matrix and without saying it say, "trust me" (good ole boy basis), not based on any industry concensus. They actually do not "connect" the dots technically and lead listners on from a poorly defined point, because the basis is not documented for the potential buyer or user to review. Not all but many do this and switch between "qualitative" to "quantitative" algorithms that are not commensurate with one another based on the software developers whim or opinion only.
Also, the real challenge,as equiment ages, is to have a tool that will allow owner operatos to make good, informed, technically sound decisions about run, inspect, repair or replace and provide a significant advantage with a reasonable effort that justifies itself - a tool that really helps you squeeze the maximum amount of life out of your equipment and processes safely and reliably and helps users make decisions on inspection, materials of construction changes, risk and POF ramifications for process and crude slate changes based on risk/cost benefit.
The basis and working process should also allow you to "sleep well at night", trusting the output. This means the technology must be technically excellent, that combined with your working process enables you to be both qualitative (e.g. assumptions by expertise) and quantitative (when you need to). This means the people involved in the process and the tool understand how much scatter is in the answer, that you ensure scatter to the conservative, and that you have metrics telling you when it is justifiable to get more data or be more quantitative, using quantitative models.
My bottome line, whatever features or buzzers and whistles you like, make sure they are subordinate to a technically excellent modeling tool producing POFs and COFs you trust and metrics that provide real value with a well documented technical basis that the software reproduces accurately. Building an inspection scheduling tool with links to graphic files etc. is relatively easy and has been done numerous times, building an excellent technical modeling tool that will help you make the tough decisions that bring real value to the operating company with confidence is quite a different story.
As far as archiving historical data;
Firstly archive only data that is worth archiving.
There are many DB programs out there for archiving whether in the RBI program, IDMS program or other program.
There are many programmers that can link or build data maps to your design.
Think about working processes, program architecture, what you ultimately want to achieve, etc. in advance so you don't "paint yourself in a corner' or have to totally redo the program in the future. that can be real expensive and time consuming.
there is so much more to share but little space and time.
Regards,
Greg Alvarado, Chief Editor, the Inspectioneering Journal |
| |
|
admin |
Posted: 09-May-09 15:07 |
|
|
|
Perhaps I did not explain them well enough. Here they are with additional clarification. By the way, I am very proud of RP 581 and the API RBI Software. Make no mistake about it. Can it be better? You bet. The API RP 581 subcommittee and API RBI User Group are constantly at work to improve the modeling and capabilities as we have been for over 15 years. Please let me know if you know of anything on this planet that is perfect or could not use improvement!
1. I provided clear definitions of the differences between 580 and 581. The reference to compliance with 581 that I made is for those who sell RBI software and do not supply a printed or written technical basis for their software and claim it it is the same as 581. There is a lot of poetic license being taken, in most cases, including the software you mention, if they do not supply a detailed explanation of the technical basis for the calculations, including algorithms or logic and formulaes. I wonder why most RBI software purveyors do not make their techical basis, in detail, available in the public domain or at least to their licensees. This stuff is not rocket science. FYI - The API RBI 581 is the only technical basis I know of that was subjected to the scrutiny of 2 independent organizations, one JBF to review the consequence logic and the other Hartford Steam Boiler to review the likelihood of failure logic for the user group to review and the group to use for further enhancement. It is also a public concensus document, created in an approved ANSI process. None of the others can make that claim.
2. Why is point 1 so important? Because the "Good Ole Boys" days of just trusting someone without a documented technical basis are waning. It is important for any owner user who implements any technology with high potential consequences whether RBI, FFS or other to know the basis intimately and make sure it is defensible, based on sound technical footing (and not just because JQ John says so) or in the US according to recognized and generally accepted good engineeering practices (RAGAGEP). One must know the details and agree with the logic, hopefully someone who would know this is RAGAGEP.
Having been a boots on the ground inspector for many years, performing over 300 internal inspections per year, I have a little experience. I see that inspectors must get out of the habit of just wanting a schedule and marching orders with little attention to the quality of the models that dictate inspection plans or intervals. It may be easy to crank out an answer in some approaches but how much can you trust them? Most of the tools I have seen, especially the qualitative ones, lose their value as excellent risk and reliability modeling tools after one or two inspection cycles because their models don't have sufficient engineering logic or horsepower to cut any further into an inspection cycle, design thickness or useful remaining life so they revert to a traditional 510 or 570 approach in the background. You really have to do your homework to make these comparisons. Returns are marginal at best for many of these other methods. Usually the main remaining benefit after one or two iterations with the qualitative tools is to take the on-stream inspection option because it is technically RBI and therefore allowed by some codes. I think this is OK, but really not fair to the stakeholder, if he/she doesn't understand this. Those POF models are usually pretty weak. And justifiably so one should not go beyond typical 510 type modeling, i.e. sans RBI, if the deeper questions aren't being asked and modeled commensurately you should be much more conservative to manage the software sellers liabilities and the safety of the user.
The inspector of tomorrow should be an Inspectioneer, a fixed equipment reliability engineer type and strategist, degreed or non-degreed. Perhaps we should have another name for the person coordinating on-stream inspection companies, watching their quality and receiving the inspection strategy list from the inspection engineer.
The inspection engineer or fixed equipment reliability strategist may or may not be a degreed engineer and should have the pro-active perspective, background, experience, education, broad-based knowledge and hunger for knowing the decisions they are making are the best they can for their employer and society and not simply doing what is convenient because they are so busy with administrative tasks of coordinating outside contractors (management is partly to blame for this dilemma). This person is largely responsible for managing the equipment for it's full life-cycle, makings sure they are getting the best return on asset life investment, reliability and availability they can at the risk level that is acceptable to their employer. This is the person who does not compromise on quality, safety, reliability and is up to the challenge, and has an excellent work-ethic and is a cut above.
I hope you are now clear on what I meant by compliance. It was not with a regulator but with software sellers claiming total or murky 581 compliance.
Greg Alvarado
[Edited by admin on 13-May-09 11:27] |
| |
|
admin |
Posted: 11-May-09 17:43 |
|
|
|
I can think of at least 3 RBI software products that claim either full or some level of compliance or strict lock step with the old and/or latest versions of 581 but use a lot of poetic license and comply with very little to maybe 50%, at best. There are a few that have done a yoeman's job. It would be highly unprofessional to post who they are without voluminous technical back-up. They should publish their basis and case histories to substantiate their claims to licensees and the public, if they wish, just as API has done. The consumer should check these things out for themselves. That is what I am promoting, nothing more, nothing less. People get what they work for. Caveat emptor!
Kindly
Greg Alvarado
[Edited by admin on 11-May-09 17:52] |
| |
|
Inspector |
Posted: 04-Nov-09 07:46 |
|
|
|
Is the API RBI software conduct the following functions automatically upon analysis (made the RBI software) to design parameters and fluid composition :
- Identify probable damage mechanisms and assess probability of failure for each damage mechanisms.
- Predict future corrosion rate.
- Assess the consequences of failure.
- Analyze effectiveness of past inspection records.
- Recommend inspection intervals and inspection task.
What are the input parameters and output information ?
Inspector engineer
|
| |
