CFIHOS is a predominantly Oil & Gas Industry standardized specification for how information regarding as asset shall be organized for Handover. This ensures the collection of data by the builder corresponds with the expectation of the operator, and the operator will understand the data they get as part of the handover, and can validate and verify accordingly.

One challenge to this worthy goal can however be that the standard is comprehensive and large, consisting of 139 tables of data with 665 fields or attributes spread across them. This also means the data is organized in a normalized data structure as opposed to the more common "flat list" of tags.

As this post takes the approach of using the Asset Objects functionality already existing in Omega 365 rather than custom-made tables and functionality, one also gains the benefit of choosing how much of the standard to implement. The challenge identified above is only a challenge if the standard asks for more data than the parties have available to them in a reasonable manner. Since the Asset Object functionality in Omega 365 is fully configurable it becomes a conversation with the customer as to how much they would like to implement.

Lets take a few entities ("tables") as an example going forward: Tag, Plant, Corrosion Loop and Corrosion Loop Type. These are 4 of the 139 entities in the standard.

We establish all entities we are concerned with, in this example only these 4, as Object Types. So we create 4 Object Types: "Tag", "Plant", "Corrosion Loop" and "Corrosion Loop Type"

At the same time, we create a Property Set for each of the Object Types. So for Tag we create a Property Set with the name "ps_Tag" to indicate this is the Property Set and not the Object in itself, and assign this Property Set to the "Tag" Object Type.

When looking at the CFIHOS standard we see that the TAG Entity has 21 attributes. These attributes must be defined as Properties in Omega 365. On this particular entity a large number of attributes are in reality Foreign Keys to other tables rather than direct entry. These are:

area code

commissioning unit code

construction assembly code

corrosion loop code

maintenance system code

maintenance unit code

parent tag name

plant code

process unit code

production critical item indicator

safety critical item group code

tag class name

tag requisition number

tag status

Whereas the remaining attributes listed below are direct entry:

designed by company name

manufacturer company name

model part name

safety critical item indicator

safety critical item reason awarded

tag description

tag name

The CFIHOS data dictionary tells us which are FKs in the "data dictionary" page, in the "constraint must be present in" column. For those who are Foreign Keys, in the setup of this Property, we specify that this Property is an Object Loop to objects of the Object Type the Foreign key relates to. This must then be done on all Properties that point to another entity/Object Type.

Also note that every piece of data in the CFIHOS standard has a Unique ID, eg. the entity "Tag" has the ID "CFIHOS-00000028". When specifying Properties there is a specific field in the setup of Properties that lets you specify the corresponding CFIHOS ID of the property.

Going back to the examples we defined earlier, the attribute/Property "Corrosion Loop" must then be an Object of the "Corrosion Loop" type. This way, when a user enters a new Tag in the Object Register, they can select among the Corrosion Loops already made as the Corrosion Loop this tag is a part of.

What we have done now is actually virtual data modelling inside Asset Objects! This is in no way restricted to CFIHOS, but applies to all datasets one might want to capture - keep in mind that there is nothing wrong with an Object Type being a non-physical component, but a virtual type that exists only to be used as meta-data on physical objects!

When we have create all the required Object Types, Property Sets and Properties, and configured these appropriately, we can start making the actual objects.

And this is where CFIHOS helps the customer in saying which party is responsible, for example Tags are the responsibility of the EPC, whereas Plant is the responsibility of the Owner. This in turn means that the Objects of these types should be created in an OrgUnit belonging to the party responsible for the information, thus enabling easy identification inside the system as to who owns, and is responsible for providing, which data.

So inside a Domain one might have an OrgUnit dedicated to the Owner and another to the EPC, and we create all "Plant" objects in the Owner OrgUnit and all "Tag" objects in the EPC OrgUnit, and when selecting the correct Plant on a Tag, the list of available Plants comes from the Owner, thus reducing double bookkeeping.

Finally, the last piece that must be in place are those entities where the party responsible for populating the Objects are neither Owner, EPC or any of the parties on the project, but rather the CFIHOS standard itself. One such example is entity "CFIHOS-00000042" - "ISO Currency". This Object Type is listed as the responsibility of RDL ("Reference Data Library"), meaning the contents of this table comes from the standard. So, the Objects of the Object Type "ISO Currency", and all other Object Types that has RDL as its data source, must be created in advance, ready-for-use by the system users.

In summary we have shown that the Asset Object functionality in Omega 365 can be used to create virtual data models of external standards without the need for custom code or custom tables. We have created Object Types with corresponding Property Sets for all Tables, we have created Properties for all Fields, and we have linked those that are constrained by another table to that Object Type.

All the while having retained the freedom to implement a partial or full data model, and if the customer chooses to implement a partial model, this has no negative consequences as they can keep adding new Object Types, Property Sets, Properties and Objects as they progress and want to encapsulate ever more of the standard!

The final step of supporting CFIHOS has not yet been done, by design, and that is supporting the import and export of the XML files that the standard dictates. This has not yet been done as this is most efficiently done together with a customer as they more than likely have an Owner or similar they can run tests against to ensure the export/import works correctly.