[[TracNav(TracNav/ISO15926Primer)]] = How ISO 15926 Will Make Your Life Easier = Status of this document: Ready for Cold Eyes Review This document is open for feedback, please post questions and comments in the forum at the bottom of this page. You will [WikiStart#Contactpoints need a login] to post in the forum. ---- [[PageOutline(2-4,Contents,inline)]] === Abstract === There are a number of issues associated with the need for interoperability, or with current attempts at interoperability. This section shows how ISO 15926 will help. ---- The value of ISO 15926 stems entirely from the benefit of being able to transfer information: * directly from one software application to another * without needing prior knowledge of either application * automatically * while maintaining the meaning of all the data values transferred Please pause for a moment to let this sink in. It is difficult to over-estimate the value of being able to exchange information with anyone, more-or-less instantaneously, without fear of transcription error, and while maintaining the precise meaning of all the terms, even though you know nothing at all about your partner's database configuration. When information is transferred correctly, the quality and reliability of your end product increase. When you know for sure that the information has been transferred correctly you can move faster because you do not have to check for errors. A very large part of designing, building, and operating plant assets involves transferring and accessing information about those assets. Some design engineers have said that they spend up to 80% of their time searching for information, transcribing information, and checking documents for transcription errors. [citation needed] In their oft-cited report issued in 2004, NIST estimated that the lack of interoperability between CAD, engineering, and other software systems costs the American capital projects industry over $15 billion every year. (A summary of the report is here: http://aecnews.com/news/2004/08/13/342.aspx To see the report itself, go to this site http://www.bfrl.nist.gov/oae/oae.html, and follow the link "Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry") All aspects of the capital projects industry involve information transfer. ISO 15926 mitigates all of the problems traditionally associated with information exchange. == Project Planning == === New Plant Construction is Risky === Some of the risk in building a new plant involves knowing what you are getting. At the same time, global competition means that we must make decisions faster. In the early stages of design, generous contingency allowances are made. Some of these contingencies involve things outside the owner's or engineer's control, but some contingencies are based on uncertainty of information. For instance, even though an engineer may have designed many similar plants in the past and may in fact know exactly what equipment needs to be purchased, getting detailed quotations is time consuming, both for the engineer and for vendors. But the whole object of preliminary engineering is to get a cost estimate without spending at lot of time. The traditional answer is to use past costs and apply an inflation factor. With ISO 15926 the cost of obtaining quotes can be decreased dramatically because it is built on the principles of the Semantic Web. Essentially, software on both the vendor's and engineer's sides will be able to communicate directly, in a greater level of detail. Engineers will be able to get detailed quotations based on past experience, without having to redo all the data sheets in the format of a new client. Vendors will be able to give detailed quotations without requiring a sales engineer to interpret data sheets. Engineers will be able to update prices on routine equipment (instead of having to concentrate only on limited numbers of high-value equipment.) Vendors will be able to expose a little, or a lot, of their product line depending on their relationship with the engineer and owner. == Project Execution == === Transferring Information === Nobody disputes the idea that transferring information manually from document to document is time-consuming and error-prone. We reduce rekeying every opportunity we get. For instance, in some situations we can use the Copy and Paste tools in office productivity software instead of having to manually rekey it. And instead of faxing hard copy back and forth and manually transcribing the changes, we routinely exchange electronic, editable, copies instead so the keyins only have to be done once. But even though we try to reduce the number of times we rekey information, it is impossible to get below "one", and we often cannot even get to that point. Anytime we have to rekey information, it takes time and provides another opportunity to make a mistake. === Fewer Transcription Errors === All participants in plant projects have a vested interest in all the information transfers, not just their own. Mistakes made in an information transaction affect more than just the two participants to that transaction. For instance: * When an engineer incorrectly transfers information from an equipment quotation to the engineering design system, the vendors can be affected. At the very least the vendors will likely have to reissue the quotation, taking their time, with no compensation. And if the mistake is not discovered until, say, startup, the vendor will get drawn into the investigation and may have to defend itself. * The opposite is also true. If the vendor incorrectly transcribes information from its own catalogue to the engineer's data sheet, the wrong component will probably be purchased and shipped. Even though, eventually, the vendor will likely have to resupply the component at its own cost, the engineer will get drawn into the investigation and may have to redo work and re-specify dependent components. * Constructors often rely on early bulk material lists from the engineer. If long-delivery items are underreported, it can affect the work schedules of itself and subcontractors. * And of course the Owner is affected by all of these mistakes. Even if the overall cost is protected by fixed-price contracts, schedule delays affect startup and commissioning, and thus the overall return on investment. All participants want information to be transferred precisely correct the first time. In contrast to traditional methods, transferring information with ISO 15926-enabled tools eliminates having to manually rekey information altogether. Thus, transferring information is much quicker, with no opportunity for error. Design engineers will be able to point their data sheet software to a vendor's web site and pull in the relevant data values. They will not have to know anything about the vendor's web site beyond that it conforms to ISO 15926. The meaning of all the data values in the engineer's own data sheets will be preserved. For instance, no one will ever have to ask questions like "Is that Design Pressure or Maximum Allowable Working Pressure?", the engineering data sheet will know what it wants and will import the correct value. === Meaning is Often Dependent on Context === One problem in mapping software applications to each other is that the meaning of terms is not always explicitly described. Every discipline has its own jargon which practitioners acquire as they gain experience. So when an engineer reviews information manually, they will usually know the context and understand what is meant. For instance, if a data sheet had a field titled "Pressure", the engineer would know what kind of pressure was intended. In some contexts it might be understood to mean "Design Pressure", in others "Maximum Allowable Working Pressure". But when machines start talking directly to other machines, the problem of implied meaning based on context becomes a serious barrier. Computer software will not, on its own, understand that "Pressure" on a valve data sheet and "Pressure" on a pump data sheet may not be the same thing. Therefore, when software engineers map one application to another, they have to be careful to fully understand what each term on each data sheet means. ISO 15926 handles this by removing ambiguity when information is modelled. The precise meaning of each term is captured when it is stored. So, to continue the pressure example, the data value itself would know whether it is "Design Pressure" or "Maximum Allowable Working Pressure". === Designing Applications to Talk to Each Other === No one who has had to manually transcribe detailed information from one data sheet to another will argue with the idea of configuring software to automatically transfer the information. The barrier, or course, is that all organizations have their information assets stored in proprietary formats. It is time-consuming and expensive to map their databases to be able to talk to each other. There are only two ways to do it: * Know a great deal about each other's databases (so, for instance, you can tell if a certain data sheet wants Design Pressure or Maximum Allowable Working Pressure.) * Design a system where the meaning of each term is somehow carried with the data value as it is transferred; then design '''Intelligent Data Sheets''' that know where to put to put each value. Neither is easy or cheap. Organizations in the plant environment tend to be shy about sharing proprietary information about how their design systems work, even with project partners. After all, partners today are competitors tomorrow. Cooperating with a project partner today could give the partner strategic information that might be used against oneself when bidding against them for a project tomorrow. Simply getting senior management approval to share such information may take longer than the actual project. But if all participants use the same standard, none of them really have to ''design'' anything. There is a learning curve for each organization's information modelers to learn how to represent plant objects, but it only has to be traversed once. In fact, this benefit, that of not having to actually ''design'' the mapping system, will be useful even for those applications that do not share information publicly. Internal applications have the same requirement to retain the meaning of terms when information is exchanged. Instead of designing such a system from scratch, an organization can simply use ISO 15926. === Database Mapping Takes a Great Deal of Time === Everyone can see the value of having all participants in a project able to exchange information with each other directly from database to database. But on a typical Fast-Tracked plant project, there is no time for participants to map their software applications to each other's once the project starts. On the other hand, there is no incentive to do so before contracts are awarded either. About the only situation where the partners in a data exchange are known well enough ahead of time, and where the volume of information justifies a custom data mapping project, is between an EPC designing a plant and the Owner. Some Owners realize that the handover of plant information is a bottleneck to efficient startup. Increasingly, Owners are specifying standards and protocols in advance as a condition of award. One only needs to look at recent examples of this sort of thing to verify that such an exercise is expensive and time-consuming. However, if all participants in plant design, construction, and operation map their databases and configure their software to comply with an industry standard, the time constraint is removed. They will no longer have to design and implement database mapping within the window of opportunity of one project. * Vendors will be able to bid on more projects * EPCs will be able to entertain more bidders * Owners can mandate more stringent standards for information turnover without limiting the field of participants. === Many Project Participants === All project participants will benefit from mapping their software applications to talk to each other. But the sheer number of pairs of participants makes doing so prohibitive. The Owner has it the worst because one way or another, it will have to pay for all the mapping exercises on its project. Even if all the information an owner receives is funneled through one EPC, all participants will embed the costs of database mapping in their prices. But if all participants map their databases to a common standard, everyone only has to map their applications once--ever. === An Example === Figure 1 is a diagram showing what might be a moderately large project. There are two engineers, three constructors, and one owner. The owner has two preferred suppliers that they want to deal with. There are five suppliers between the two engineers, and five suppliers between the three constructors. [[Image(Benefits01.JPG, 600px)]] '''Figure 1: One Owner, Two Engineers, Three Constructors''' There are 18 players with 45 different connections between them. Remember that each colored line represents a separate mapping project, involving hundreds or, in the case of the EPC-to-Owner transfer, thousands of data point maps. Each engineer and constructor will only have to map the databases for the suppliers and partners it dealt with. But the Owner will end up dealing with them all after the plant is commissioned. Even if the Owner was willing to pay for all the custom database maps (either explicitly, or built into the prices) the speed in which they would have to be created will prevent it from happening. Once a client signs an agreement to begin detailed engineering, there isn't any time to spare. To require all bidders to submit to a database mapping exercise before submitting bids would delay the project significantly. Of course, no one would ever do this. Wouldn't it be nice if the whole world would agree on a common manner of describing plant objects and a common meaning of the terminology? Then we could just tell each other "Have your machine talk to my machine." == A Metaphor: We Need a Babel Fish == To re-use a metaphor, we need a Babel fish to translate from one company's data sheets to those of another. * [wiki:ISO15926Primer_Metaphor_Babelfish ISO 15926 is like a Babel fish] [[Image(Benefits02.JPG)]] '''Figure 2: Everyone Needs a Babel fish''' Fortunately, ISO 15926 acts very much like a Babel fish. * Each company creates what is known as a ''façade'' and makes it publicly available on the Internet. * Each company maps its own database (or at any rate, those portions of its database that it wishes to publish) to the ISO 15926 standard. * Each company creates an application which can access the façades of its business partners. After that, the only question you have to ask of a supplier (or engineer, or constructor) is "What is the URL of your façade?" [[Image(Benefits03.JPG, 600px)]] '''Figure 3: The Same Project Using ISO 15926 Facades''' Using ISO 15926 Facades, these same 18 players would only need 18 façades, one each. But the best thing is that they would not have to create a new set of connections with each project. They would only have to do it once, ever. The colored lines, from each company to its façade, is all most organizations would have to create from scratch. The black lines between façades represent functions built into commercial software. === Data Requirements Change Rapidly Over Time === Even in the unlikely event that a consortium of vendors, engineers, constructors and operating plants were to agree on the precise definition of all their terms, the agreement would be fragile. It is not controversial to note that we live with constant change. In fact, the only thing we know for sure is that the pace of change is picking up. New equipment and new methods of control will require information systems that we cannot now imagine. When faced with change, the consortium will have only three choices: * To come up with a bureaucracy large enough to change the standard fast enough to keep up. * Ignore the technology change for the sake of keeping an old standard. * Design some kind of standard that handles change. ISO 15926 is in fact a standard that handles change. Designing such a standard (for exchanging information that handles change) is no easy feat. It requires a deep understanding of how people convey meaning. It goes beyond placing meta tags on a web page for search engines. The scope of ISO 15926 is well beyond what one organization could handle on its own. By using ISO 15926, organizations take advantage of work already done. Learning to use ISO 15926 is well within the grasp of any organization in the plant industry. It is an open standard that anyone can use without having to pay royalties. With proper training to its personnel, any organization can extend the standard at any time to deal with technological change. No large bureaucracy is required. If the extensions are truly of value to the industry, other participants will adopt them, and the change will be come standard amongst many companies. If the change is not deemed to be of value, it will be simply ignored. === Compatibility with Proprietary Systems === Most organizations in the plant industry have proprietary ways of managing information that they regard as competitive advantages. They will not easily abandon these systems out of an altruistic desire to conform to an industry standard. One advantage of using ISO 15926 is that organizations do not have to modify any of their internal systems. All that is required is to map its internal applications to the ISO 15926 standard, and to create a façade that will allow outside parties to request information. Eventually, as it modifies those internal systems over time, the organization may find that adopting ISO 15926 internally is easier, but there is no obligation. In fact, there is no requirement that an organization make any statement at all about its internal applications. === Organizations Do Not Want to Expose Everything === Most organizations want control over how much of their internal operations are made public. A standard that required full transparency would not gain much traction. ISO 15926 makes no requirement of how much of its internal operations an organization exposes. The only requirement is that when the organization publishes information, that the information follow the standard. The organization has full control over what is exposed, and to whom it grants access. === Data Storage Technology Changes Rapidly === The lifetime of particular Information Technology is measured in years. The lifetime of the average plant is measured in decades. If crucial plant information is locked in the proprietary system of obsolete software, owners will be faced with the dilemma of loosing the information or converting it to the replacement system. If the technological change is just new storage media, the plant information just has to be read onto the new media. But if the technological change is a new Enterprise Requirements Planning (ERP) system, moving the plant information becomes a database mapping project in its own right. ISO 15926 removes concern over technological change by the very means of storage. Although ISO 15926 can be expressed in many different software applications, from spreadsheets, to databases, to custom software, at its basic form it is simply ASCII text files. While you might ''store'' the information in a database, ''what'' you store is text written in a dialect of Extensible Markup Language (XML). If worst comes to worst, you can always print an object description and read it. === Not an All-or-Nothing Mapping Project === Mapping databases so software applications can exchange information using the ISO 15926 standard is not an all-or-nothing affair. There are several levels an organization can work toward, each giving an incremental benefit. As returns are made on the investment in ISO 15926, more development can be funded, eventually ending with full compliance. == Plant Operations and Maintenance == Plant information requirements are becoming more onerous. Ensuring the health and safety of a plant's operations staff means that information about dangerous substances and hazardous equipment must be quickly available at all times. Plant assets are becoming more sophisticated and complex. Failure to manage information about plant assets compromises their reliability. Managing information about plant assets using traditional methods usually involves requesting equipment maintenance information via the EPC or commissioning contractor. But getting complete and accurate information via a third party is hampered because neither to EPC or commissioning contractor has a vested interest in it. === EPCs and Owners Information Needs are Different === The design engineer asks: * Is this thing actually the correct thing? * Is it in the correct place? The owner asks: * Is it still working? * How can I keep it working? or * How can I fix it? An engineer needs calculations to show that a given equipment (or pipe, or instrument) is correct for the plant in question. She needs to know that everything can be built at the location planned. And in the end, every engineering document is potentially evidence in a court of law, many years later. It is important to be able to retrieve proof that she acted competently. An owner, however, assumes that the equipment is correct (after all, the plant is operating), and that there are no clashes (after all, the plant has been built.) He is interested in things like indicators that the plant is running smoothly, and maintenance schedules to keep everything in that state. ISO 15926 does not assume that every participant will want to know ''everything'' about ''everything''. For instance, a corialis meter may have 4000 data values associated with it. This does not mean that every participant has to receive all 4000 values. When your software queries the façade of a business partner, it can simply request the few data values that are of interest, and leave the rest. On the other hand, because the ISO 15926 standard is concise (even though it may not be brief) an organization ''could'' ask for everything without obscuring the few it was interested in. To continue the example, if one organization had interest in only 10 of the data values, the presence of the other 3990 would not make the 10 any harder to find. == Turnover == === Plant Information is Most Useful During Commissioning === The time a plant is most at risk is during commissioning. Operators are new, the plant may have a new generation of equipment, and the process may be new. If equipment does go down it is important that maintenance information and spare parts be available quickly. But information turnover by traditional means may not even have started yet. === Information Standards Can be Complex === Without specification in advance, an EPC will turn information over to the Owner in the easiest and cheapest manner it can get away with. If this manner were the optimum manner for the owner, it would be an amazing coincidence indeed. But developing proper standards takes time, as we have seen. If the owner and EPC both adopt ISO 15926, the problem goes away entirely. === Proprietary Information Standards can Limit Competition === While it is true that good information standards, specified in advance, means that the information turnover will go smoothly, requirements to conform to proprietary standards can restrict competition, and thus tend to increase the cost to the owner. But if most owners adopt ISO 15926 as the format for information exchange, engineers and suppliers will conform willingly. Costs for information transfer for all participants (and for the owner who in the end pays for everything) will reduce. Everyone wins. == Future Possibilities == We are at the beginning of widespread implementation of ISO 15926. We are justifying this based on automating current work processes. But more possibilities are being discovered as we go. Comparing ISO 15926 to the time line of cellular phone technology, ISO 15926 is only at 1973, where people marveled that one could walk across a busy New York street while carrying on a telephone conversation. (Although some bystanders were more in awe of the street-crossing part than the talking-on-the-telephone part!) === Market for Niche Applications === When ISO 15926 becomes mainstream, it will be easier to implement software that requires a large amount of plant data. Currently, developers of this kind of software would have to spend considerable effort to import the plant data. With no industry standard, the software developer will have to deal with every unique plant. All this means that the threshold for this kind of software is quite high. But if an Owner/Operator exposed its plant configuration with an ISO 15926 façade, pulling information into the software would be trivial. === Rule-Based Engineering === 3D design systems are beginning to support Rule-Based Engineering (RBE). Examples: * If you move a pump in a 3D model, the foundation moves too. * If you attempt to modify a storage tank, you will be advised that the item has already been purchased. RBE has the potential to increase engineering efficiency and reliability. Unfortunately, all software to date that supports RBE tie all the rules an organization develops to the particular system. But if these rules are developed with ISO 15926 methodology, they will be portable. == Summaries == * [wiki:ISO15926Primer_Benefits_OO Benefits for Plant Owners and Operators] * [wiki:ISO15926Primer_Benefits_PM Benefits for Project Managers and EPCs] * [wiki:ISO15926Primer_Benefits_OEM Benefits for OEM] * [wiki:ISO15926Primer_Benefits_Software Benefits for Software Vendors] === Next === [wiki:ISO15926Primer_History History of ISO 15926] Interoperability of digital information between computer systems became and issue almost as soon as computers made their way into engineering offices. ---- [[ViewTopic(ISO15926Primer_Benefits)]]