Gellish Communicator - User Manual
Table of content:
Gellish Communicator - User Manual
Table of content:
The creation of Facility Information Models is one of the parts of the Gellish Modeling Method, as is described in the overall Gellish Modeling Method - Architecture document. When such an information model concerns a plant, a product, a building, etc., then the result can be called a Plant Information Model, a Product Information Model, a Building Information Model (BIM), etc.
Other parts of the method deal with Dictionaries (Definition Models, arranged as a Taxonomy), Knowledge Models and Requirements Models. They are concerned with models of kinds of things. Facility Information Models are concerned with the modeling of individual things and the information about them.
This part of the Gellish Modeling Method aims to increase the quality and accessibility of information (documents and data) about a facility and at the same time to reduce costs of managing data about the facility and its use. The basic vehicle for that is the development and use of an integrated electronic
Facility Information Model. Such a model is a model of an individual thing that can be either a design of a particular object or it may be real a world object, or both. For example, it can be a design of a complete process plant, a building, a road, a ship or an airplane (which designs are imaginary individual things that only exist in peoples minds), and it can be an object that is fabricated, constructed and installed, operated and maintained.
This paragraph describes what a Facility Information Model is and it specifies the procedure to create such a model.
A Facility Information Model that is created according to the Gellish Modeling Method is preferrably documented in a system independent way in one or more standard Gellish Database tables. This means that the model can be imported in any system that is able to read Gellish Database tables. That is the reason why these pages don't discuss any particular software system, but only deal with their data and document content.
Important kinds of systems in which Facility Information Models will most likely be implemented are document oriented systems, such as extended Electronic Document Management Systems (extended EDMS’s), Content Management Systems (CMS systems) or Enterprise Content Management Systems (ECM systems). Another kind of systems in which Facility Information Models may be implemented are more data oriented systems, such as Product Data Management Systems (PDM systems) and Product Lifecycle Management Systems (PLM systems) or ERP systems, typically extended with 2D drawing and 3D shape representation capabilities.
Traditionally information about a facility is recorded in documents, first in paper documents, later in electronic documents. In a Facility Information Model a core part of the information is expressed as data, which data reflects the facility and its components and their operation and possibly their properties, whereas another part consists of the remaining documents. Each of those documents is then related to the element in the facility model about which the document contains information. Figure 1, Facility Information Model Architecture
A Facility Information Model generally has an Architecture as is presented in Figure 1. Such a model typically consists of three, four or five sections:
1. A Facility Model.
A Facility Model consists of data in a structure, so that it forms a model of a facility, its components and its processes and properties. This may reflect the design of a facility or it may describe an actually fabricated facility, or both.
The Facility Model section includes a composition hierarchy (also called a breakdown structure) of a facility (being a process plant, ship, building, road, etc.) as well as the properties of its components. It may also include the processes that take place in the facility together with the processed materials and the activities on its components.
2. Document Models.
Document Models consist of documents that are related to the facility, together with data about the documents. A Facility Information Model shall include relations between the documents and the elements in the facility model about which they provide information. This section includes the repository of documents about the facility as well as the procedures to operate, inspect and maintain it.
3. Requirement Models.
Requirements Models form an optional section that describes requirements about the kinds of things in the facility model, specified in the form of relations between concepts in the Dictionary (<shall have…> or <shall be…> relations). For example: a compressor <shall have as aspect a> capacity. A special type of Requirements Models is called Standard Specification models that define standardised types of components. For example, Standard Specification Models of standardised bolts
4. Knowledge Models.
Knowledge Models form another optional section that describes knowledge about the kinds of things in the facility model, also specified in the form of relations between concepts in the Dictionary, but using different relation types (<can have…> or <can be…> relations). For example: a building <can have as aspect a> number of levels.
5. Dictionary (Definition Models).
An Electronic Dictionary defines the kinds of components, kinds of documents, kinds of processes an kinds of properties, etc. in the application domain of the model. It defines the 'common language' of the Facility Information Model. An electronic Gellish Dictionary is arranged as a Taxonomy and consists of Definition Models that define concepts by a model of the facts that are by definition the case. The Gellish English Dictionary is an exemple of such an electronic Dictionary.
Each element in the Facility Model is related by a classification relation to a concept in the Dictionary.
Each document is related to a document type, which is also part of the Dictionary.
The Facility Model, Document Models and a Dictionary together form the core of a Facility Information Model.
A Facility Information Model can be described as a network of related things. In other words it consists of 'objects' with relations between those 'objects'. Those relations include not only relations between components of the facility model, but also relations between the components and the processes, activities, properties (including also shapes and coordinates) and documents.
So, a Facility Information Model is the integration of a set of data and documents that model and describes the facility, its operation and maintenance, whereas each component and each document is classified by a concept (a class) that is defined in an electronic Dictionary, such as the Gellish English Dictionary or a Gellish Domain Dictionary.
A facility information model can be implemented in various ways. The essence is that the user of a system by which the data and documents are accessed should experience it as one integrated system. Nevertheless, the system may be constructed such that the documents are stored in a simple directory or such that they are be stored in a separate document management system and the data are stored in one or more databases.
The process to create an electronic Facility Information Model will depend on the available material, the phase in the (project) lifecycle of the facilities and the intended scope.
The creation of the Facility Information Model may start for example with the following source material:
The management of Bills of Materials, Equipment lists and Document indexes requires that revisions of those lists should contain an indication of each fact that is changed. This is necessary to enable a proper update of the database This means that it shall be indicated whether an equipment item or document is deleted, modified or added, relative to the previous version.
Typically the following steps are then taken to create the backbone of a Facility Information Model:
1. Create a facility composition hierarchy (also called an asset breakdown structure).
1.1 Make coded names (tag names) and unit names consistent and compliant with a standardized convention.
1.2 Classify components, equipment and units. This implies: Classify the site, the plant(s), process units, buildings, roads, systems and their components.
1.3 Decompose the facility. This implies: Specify for each component of which assembly (or assemblies) it is a part and add systems and include them in the decomposition hierarchy.
The result will be a Gellish database table. An example of the core of such a table may be as follows:
B1 <is classified as a> building
B1 <has as part> C1
C1 <is classified as a> HVAC system
C1 <has as part> C2
C2 <is classified as a> cooling unit
2. Specify document auxiliary data (meta data) and file names.
2.1 Make document titles consistent.
2.2 Classify documents. This implies: Classify each document by standard document types.
2.3 Decompose documents where appropriate. This implies that for some documents (e.g. binders or multi-page drawings?) a decomposition shall be specified.
2.4 Add version succession of documents. This implies that documents that are succeeded by new versions shall be related to their successor.
This step and also the followings steps also result in a Gellish Database table.All those tables together form the Facility Information Model.
3. Relate documents to equipment.
Specify for each equipment item on which document it appears, or for each document about which equipment items it contains information.
4. Relate documents to files at addresses.
Specify for each document on which a physical medium it is presented, either as an electronic data file or on paper, microfilm or any other medium.
5. Identify installed items and relate them to designed items.
Specify for each installed item for which design item (tagged item) it is installed and identify the manufacturer’s models that are applied.
6. Add activities and processes (functions).
Specify which processes (functions) are or will be performed in or by the facility and its components and which activities are performed by people that operate or maintain the facility and its components.
7. Add aspects to the components.
Specify the properties, qualities, dimensions, shapes, coordinates and other qualitative and quantitative aspects of the facility and its components and possibly to the activities, processes and products.
8. Add other facts (relations)
Specify additional information as required to complete the specification.
Once the Gellish Database tables are created they can be directly used by a Gellish Viewer to search for information and documents about the facility and its components. They can also be exchanged and combined with Gellish Database tables that contain additional information about the facility.
Continue with Product Modeling