Representing a system

28 Nov. 2010, revised 1 Dec. 2010

Introduction

This topic deals with the philosophy of a practical representation of a system.

Philosophy

For this topic we'll take the example of a pump function/system, as discussed in another topic. Let us first define what this pump function/system is about:

Electric motor-driven pump set with its subfunctions / subsystems

The philosphical question here is how far we need to go in mapping all information of these subsystems into ISO 15926. My position in this may surprise you: not very far.

For the functional side we need for:

  • Motor Controls:
    • the schematic diagram, covering the MCC (Motor Control Centre) slot, the power and controls cables and the switches;
    • the P&ID on which the controls are shown (if applicable);
    • the specifications for the hardware.
  • Motor: the specification (often part of pump specification)
  • Coupling: the specification (often part of pump specification)
  • Pump:
  • Piping:
    • the P&ID on which it is shown
    • the Pipe Spec.
    • the Process Data Sheet

For the physical side we need for:

  • Motor Controls:

  • Motor: the Operations & Maintenance Manual

  • Coupling: the Operations & Maintenance Manual

  • Pump:

    • Test Report
    • the Operations & Maintenance Manual
    • the foundation details
  • Piping:

NOTE1 - The pump system and the piping system overlap (same as the instrument loop with a control valve and the piping system)

NOTE2 - This list is not necessarily complete, but serves to bring the idea across

Do you need to map these documents to ISO 15926?

Use ISO 15926 first to integrate all process equipment, electrical equipment, instruments and instrument loops, and piping as shown in another topic, as functions and systems as parts of the plant, and then decompose these functions as indicated above. Expressing all connection details of piping, cabling and wiring in ISO 15926 is too cumbersome, and can better be done on documents.

Store all documents, with all their revisions, in a document management system and make them accessible by means of a URL. For each (sub)function and (sub)system the set of documents, with a revision for the set (paradigm shift required !) is determined using instances of ClassOfCompositionOfIndividual and ParticipatingRoleAndDomain. Go to the topic Document Handling to see why.

So, for the above pump function we collect all documents. It is most efficient to collect the documents per subfunction, and then collect the subfunctions into the main function.

At the individual level of FunctionalPhysicalObject we then have (in the above case) an instance for the pump function that is classified with the instance of ParticipatingRoleAndDomain, that in turn collects the instances of ParticipatingRoleAndDomain that collect the documents of the subfunctions.

That instance of FunctionalPhysicalObject then is decomposed into instances for the subfunctions, each of the latter being classified with the instance of ParticipatingRoleAndDomain, in the latest version, for that subfunction.

Model

In order to keep the size of the diagram below presentable the three subfunctions Motor-Coupling-Pump are combined into PumpSet

Collecting the functional documents for a pump function

Classifying the functional physical objects

Finally the instances of FunctionalPhysicalObject are classified:

Classifying the functional physical objects

Advantages and disadvantages of this approach

The main advantages are:

  • The documents are retrievable by function and system, with all their subfunctions and subsystems, and allways in the latest revision.
  • It is not necessary to fully model all detailed compositions and connections, and still have the information readily at hand.

The disadvantages are:

  • It will take a learning curve, also for the existing document management systems
  • Each addition or revision creates a bottom-up avalanche of revisions of the 'containers'; it would be advisable to give the containers the date-time as revision number.