| Version 27 (modified by gordonrachar, 16 years ago) |
|---|
TracNav menu
ISO 15926 Primer
Status of this document: [Working Draft]
This is the beginning of the Primer for ISO 15926. It is open for feedback in the forum at the bottom of this page. You need a login to post in the forum.
Why Do We Need ISO 15926?
The short answer is: "So So we can exchange complex plant and project information easier and cheaper."
A slightly longer answer is: "To mitigate the current high costs of rekeying, and reformatting information to move it from one proprietary system to another."
For example, take the task of designing and specifying a process instrument for a plant modification. Imagine how many times information has to be rekeyed after the instrument is basically designed, until it is installed and commissioned in the target plant:
- After design, enter the information into From the design datastore, likely a datasheet in Excel, or a database.
- Each bidder will enter some of the data values into proprietary software to make a selection.
- After selection, each bidder modifies some data values and transmits it back to the engineer.
- Rekey certain data values from the winning bid into the engineer's premanent database.
- Data turnover to the client is likely something like an excel file for each datasheet.
- The owner will rekey certain data values into an asset management system.
[Feedback Requested. We want to end up with all of instances, in this information chain, of having to rekey information that 15926 will mitigate]
The situation is improving. A few years ago the datasheets would have been printed and faxed to the vendors who would manually add what they had to and fax them back--now we email editable electronic files. There are also proposals to streamline the final handover so that it is already in the form required for the owner's Asset Management System--but the configuration costs speak to the complixity of the issue.
What we need is a way for each participant's software to be able to communicate complex information to each other without having to know in advance what needs to be communicated.
ISO 15926 is a Babel Fish
If you wanted to listen to Vogon poetry spoken in the original, you might use a Babel Fish.
The Babel Fish would listen to the Vogon speaking, then rearrange the syntax and translate all the words all on the fly, so to speak.
ISO 15926 acts like a Babel Fish by acting as an interpreter between two otherwise incompatible systems.
Sharing Instrument Information Under ISO 15926
Compare the process instrument example above to doing the same thing with ISO 15926 tools.
Initial data entry is the same:
- Initial data entry is the same: After design, enter the information into From the design datastore, likely a datasheet in Excel, or a database.
But thereafter, tools written to support the ISO 15926 standard extract the relevent information automatically:
- Each bidder will use an ISO 15926 tool to automatically select the relevent data values from the Request for Quotation and paste it into proprietary software to make a selection.
- After selection, each bidder will use another ISO 15926 tool to copy the relevent data values and paste them into a communication back to the engineer.
- The engineer will use the same kind of ISO 15926 tools to copy the relevent data values from the bidder's communication into his premanent database.
- Data turnover to the client will be exposing the plant information database with a ISO 15926-compliant interface (known as a facade).
- The owner will open the link to the engineer's plant information database in import whichever data values are of interest.
You can see that if we use 15926 tools we are removing a great many opportunities for human error. So in addition to being able to transfer information faster, we will remove the labor-intensive tasks and make the whole process more reliable.
How ISO 15926 Makes Sharing Information Easier
ISO 15926 is a world-wide standard interchange format for rendering complex information about plant objects into a common format so we can all communicate without having to know anything about each other's data storage configuration. Everyone will still have their own datastores, perhaps in a proprietary format, but will employ a Babel Fish (known as a "facade") when they send or receive information from others.
Thus, a consortium of EPCs could collaborate on designing a plant, each using its chosen plant design system with proprietary work processes. They could share information without having to know anything about each other's data storage format beforehand. Vendor's and EPC's software would connect to each other passing information back and forth.
Turnover from EPC to Owner would be a non-issue. Owners would recieve the plant data by essentially filtering it through their Babel Fish (i.e., facade) and then store it in the their own format. Any of the owner's computer systems would be able to use the information. A Plant Operating System would access the pieces of information it needed. A Plant Maintenance System would access the pieces it needed. Each application will take the pieces it needs and ignore the rest.
The Opportunity
With a common language for complex plant information, enterpreners will be able to write niche applications easier. For instance, someone might write an optimizer for a certain process that simply opens the plant datastore and finds the particular process information it needs. Since the format of the input information is no longer an issue, software developers can concentrate on the new value-added functionality.
Author:
- Gord Rachar, mailto:Gordon.Rachar@…
