| Version 14 (modified by gordonrachar, 15 years ago) |
|---|
TracNav menu
- An Introduction to ISO 15926
-
What is ISO 15926
- How Information Exchange is Supposed to Work
- How Information Exchange Actually Works
- How Information Exchange Works with ISO 15926
- How ISO 15926 Works
- A Bit of History
- Long Tail
-
Areas of Current Work
- Norwegian Continental Shelf
- MIMOSA
- JORD
- iRING
- Development of Standards
- Educational Material
- Getting Started With ISO 15926
- Other ISO 15926 Resources
-
Introduction to ''An Introduction to ISO 15926''
- ISO 15926 is Like a Babel Fish
- ISO 15926 is Like HTML
- ISO 15926 is Like English on Your Cell Phone
- About the Author
- ISO15926Primer_DiagnosticPage
Getting Started with ISO 15926
Status of this document: Working Draft
This document is open for feedback, please post questions and comments in the forum at the bottom of this page. You will need a login to post in the forum.
Contents
- Abstract
- Read the Primer
- Appoint an "Information Czar" (or Czarina)
- Map your System Landscape
- Develop a Business Case
- Develop a Plan
- Look at the Relationships
- Decide Compliance Level
Abstract
[Enter abstract]
Read the Primer
Develop a basic understanding of ISO 15926. Understand some key points:
- Using ISO 15926 you can exchange information with others without having to know anything at all about each other's data storage configuration.
- Information will be transferred directly from machine to machine without having to be rekeyed.
- The information will be transferred with high fidelity. You no longer need human beings to review every piece of information to make sure nothing is lost or added.
Appoint an "Information Czar" (or Czarina)
Information is one of your organization's most valuable assets. You probably already have leads for your most important departments. For instance, engineering organizations have titles like "Principle Process Engineer", or "Lead Mechanical Engineer". Operating companies will have someone in charge of maintenance. You should also have someone in charge of managing your information.
This is not the same a "Chief Information Officer". The typical CIO nowadays is more interested in the hardware and infrastructure software than the content, whereas the "Information Czar" is only interested in the content.
Good attributes for the Information Czar:
- A background in your organization's business.
- A mind set that the "information asset" is worth as much as the "physical asset."
- The ability to differentiate between a "physical object" and an "abstract object."
- An understanding of database and computer programming concepts will be an asset.
Map your System Landscape
You will need to know all the individual software applications your organization uses, where they get their input from, and where their output goes. Map all of the information exchanges. Your most important applications will probably already be mapped together either with custom programing or commercial middleware. Other information exchanges might be made manually every time with exchange files or ad hoc software. Map all of them, even if they seem to be working properly.
Look for an opportunity to improve an information exchange by using ISO 15926. A good first step is to map both sides of the exchange using Part 4, the dictionary. Following are some examples:
Automate a Manual Exchange
In this example your software applications are primarily stand-alone. Input for all applications is entered manually. If the input for an application is created by an upstream software application, the information must be rekeyed. What you would like to do is automate the data input and output for one of the applications.
Figure 1 - Manual Information Exchanges
To automate this you need to create a database map to transfer information from Application A to Application B, and from Application B to Application C. But instead of making two custom dtabase maps, make the maps to ISO 15926-4.
Figure 2 - Map to ISO 15926-4
Encapsulate an Application
In this example, information moving from one appliction to another is already automated by means of custom database maps. Perhaps you wish to modify the application but don't want to make all the upstream and downstream links break.
Figure 3 - Hard-Coded Custom Map
What you want is to Encapsulate the application using the 15926-4 dictionary. Thereafter, if you modify the application, all you have to do is make sure the inputs and outputs are still mapped to 15926-4.
Figure 4 - Map to ISO 15926-4
De-Ossify a Confederation of Applications
In this example you have a number of applications that are linked by a common database. This is better than individually mapped applictions, but will still need maintenace whenever any of the applictions change. Even new updates to commercial software can break the link.
Figure 5 - Applications Mapped to a Common Database
In order to isolate, say, Application A so that you can update it independently, you will need to create a map between ISO 15926-4 and the common data dictionary.
Figure 6 - Map to ISO 15926-4
Develop a Business Case
There are a number of potential justifications, but all involve moving information from one data store to another:
- Saving Money - For instance, if you have to repeatedly map one application to other applications. If you use ISO 15926 you only have to map it once more.
- Saving Time - For instance, if you repeatedly have to map applications to other, external, applications in a short period of time. If you map to ISO 15926, the application will be ready to exchange information with any other ISO 15926-compliant application.
- Interoperability of Internal Applications - For instance, if your organizations run many proprietary applications that have to talk to each other, instead of mapping each of them together one pair at a time, map each to ISO 15926.
- Experience - For instance, if you anticipate having to implement ISO 15926 for many of our proprietary applications but don't know enough to make an accurate estimate.
Develop a Plan
Pick a pair of applications that need to exchange information. It can be any two, but the first implementation will go smoother if the two applications smallish, and are internal to your organization.
If your existing staff are not sufficiently experienced (as is likely), identify which vendors and consultants can help you.
Compare the schema of the two applications to ISO 15926. That is, find out the database objects in both applications and list their properties.
For example, suppose you want to be able to extract information from a PDS project to a Purchasing application:
| Application Name | Native Class Name | Native Properties | IS) 15926 Class Name | ISO 15926 Properties |
| PDS | Valve | Nominal Diameter | ||
| Pressure | ||||
| Temperature | ||||
| Purchasing App | ||||
This is not mapping, you are doing this to develop the scope and get into the RDL classes to see what is there. You may find that a class is not in the RDL, and that's OK. You will eventually have to extend the class, thereby contributing to the industry information asset.
Look at the Relationships
The next step is to look at the relationships coming from the objects. For instance, what is the relationship between a valve and a pipeline, or between an instrument and a pipeline?
Then step into ISO 15926-7 to see the closest template. Map your relationships to the standard relationships. As before, if you need to extend the relationship templates, that's OK.
Decide Compliance Level
- Yellow - Only uses reference to reference data
- Green - Only uses shortcut style of templates
- Blue - Uses Part 7, not 8
- Red - Uses Part 7 & 8
- Red+ - Uses Part 7, 8, & 9
