Hazardous Area Information Development and Retrieval

Abstract

Abstract A hazardous area information development method and system as disclosed. During designing a plant comprising a hazardous area an identification is allocated to one or more components of the hazardous area. For each component, the identification is recorded against information related to the respective component is a storage. During building the plant, each component is tagged with an indicator of the identification of the component. The indicator of a selected component of the plant is able to be read so as to determine the identification of the selected component; and the recorded information about the component can be retrieved from the storage according to the determined identification of the selected component. Abstract2020203768 08 Jun 2020 Abstract2020203768 08 Jun 2020 2 FIG. 2 60: Design 70: Build 90: Operate 62: Determine / Specify Components 64: Identify each Component 66: Record Information on Components 72: Install each Component 74: Tag each Component 76: Record install info on each Component 78: Verify each Component 80: Record each Verification 92: Inspect each Component 96: Repair / maintain each Component 98: Record changes 94: Retrieve information on Component 20 20 20 37 68 0 8 Ju n 20 20 2 62: Determine 66: Record Information on 2020203768 08 Jun 2020 70: Build 72: Install each 76: Record install info 80: Record each 98: Record maintain each 94: Retrieve information on FIG. 2 2 62: Determine 66: Record Information on 2020203768 08 Jun 2020 70: Build 76: Record install info 80: Record each 98: Record maintain each 94: Retrieve information on FIG. 2

Description

Hazardous Area Information Development and Retrieval Background

[0001] Hazardous Area Verification Dossiers (HAVD) are used by inspection personnel to record evidence of regulatory compliance as well as maintenance and replacement of equipment in hazardous areas.

[0002] These documents are typically produced in a paper form but are sometimes in electronic document form.

[0003] To access information in a HAVD, the physical paper document is accessed and the information reviewed. When an update occurs, the paper documents are added to the dossier (or electronic document are stored in an archive folder).

[0004] Sometimes equipment is tagged with an identifier. Historically, once a tag is inspected, the result of the inspection “inspection passed” may be saved with reference to the tag. However, any prior information is overwritten / modified. Further a data update to a centralised datastore will over-right all past data, which can result in a loss of data. This can result in components needing to be re-inspected because the inspection data is lost.

[0005] The present invention has been development with this problem in mind.

[0006] Any document, reference, patent application or patent that might be cited in this text is expressly incorporated herein in their entirety by reference, which means that it should be read and considered by the reader as part of this text. That the document, reference, patent application, or patent cited in this text is not repeated herein is merely for reasons of conciseness.

[0007] In this specification, where a literary work, act or item of knowledge (or combinations thereof), is discussed, such reference is not an acknowledgment or admission that any of the information referred to formed part of the common general knowledge as at the priority date of the application. Such information is included only for the purposes of providing context for facilitating an understanding of the inventive concept / principles and the various forms or embodiments in which those inventive. Summary of the Invention

[0008] According to a first aspect of the invention there is provided a hazardous area information development method comprising: designing a plant comprising a hazardous area; allocating an identification to one or more components of the hazardous area; for each component, recording the identification against information related to the respective component; building the plant, tagging each component with an indicator of the identification of the component; whereby the indicator of a selected component of the plant is able to be read so as to determine the identification of the selected component; and so that the recorded information about the component can be retrieved according to the determined identification of the selected component.

[0009] In an embodiment the method further comprises retrieving the recorded information about the component according to a determined identification of one of the components.

[00010] In an embodiment the method further comprises appending further information in the stored information about the component over time and scanning the tag to access the stored information about the component at a subsequent time.

[00011] According to a second aspect of the invention there is provided a hazardous area information retrieval method comprising: in the engineering / design phase of designing of a plant comprising a hazardous area, allocating an identification to one or more components of the hazardous area; for each component, recording the identification against information related to the respective component; in the build phase of construction of the plant, tagging each component with an indicator of the identification of the component; in the operation phase of the plant, reading the indicator of a selected component of the plant so as to determine the identification of the selected component; and retrieving the recorded information about the component according to the determined identification of the selected component.

[00012] In the above aspect there may be the following features.

[00013] In an embodiment each component has a component type. In an embodiment the recorded information for each component comprises the component type and information specifically related to the respective component. In an embodiment the recorded information for each component comprises information related to components of the component type.

[00014] In an embodiment the components are organised in a hierarchy of systems, sub-systems and individual components thereof.

[00015] In an embodiment the indicia also comprises the component type.

[00016] In an embodiment the step of retrieving the hazard information also comprises retrieving information about the component type.

[00017] In an embodiment the method further comprises recording a change made to the component against the component identification.

[00018] In an embodiment in the build phase the method further comprises recording with the information about the component an item / part identifier of the installed type of component.

[00019] In an embodiment the item identifier comprises a serial number. Thus, the component identification is an identification of the component in the plant, not an identification of the individual component, such as an item / part serial number.

[00020] In an embodiment, in the operation phase when one of the components is replaced then the method further comprises recording the changed item / part identifier against the component identifier in the plant. Thus replacement of a component in a plant does not change the component identification, only the item / part identifier.

[00021] In an embodiment, in the operation phase when one of the components is changed then the method further comprises recording the changed component identification and information relating to the component.

[00022] In an embodiment the recorded information comprises one or more of the following: hazardous area classification; drawings and / or models of the hazardous area; sources of release of hazardous substances (eg sources of release of flammable fluid); intrinsic safety (IS) calculations; conformity to standard(s) requirements assessment document; fitness for purpose report; models and data for import from or export to a 3" party software and / or drafting package to identify a Hazardous Zone; 3D models of the plant or components of the plant; 2D models of the plant or components of the plant; computer flow dynamic model for each component.

[00023] In an embodiment after the design phase and prior to the build phase, Inspection and Test Report (ITR) data are compiled from the recorded information for each component to be installed during the build and the Inspection and Test Records are completed upon completion of the build phase with information derived from the build phase, such as when additional information is developed to ensure compliance. Each ITR is recorded in association with the component identification.

[00024] In an embodiment the information available to an inspector during the operations phase may be restricted.

[00025] In an embodiment the ITR is presented in the form of a document for completion by an inspector. In an embodiment the ITR is an electronic form.

[00026] The completed form comprises as attachments information obtained from the retrieved record associated with the component identification. This comprises at least one or more of the following: a previous certificate of conformity; conformity assessment documents; intrinsically safe calculations and information; fitness for purpose documents; Simple Apparatus Assessments; calculations (eg. heat calculations and IS calculations).

[00027] This information is locked from modification unless certain criteria are met.

[00028] In an embodiment the indicator is a near field device (such as an RFID tag), a bar code, a QR code, a readable label with an identifier printed on it, or other suitable identification means.

[00029] According to a third aspect of the invention there is provided a hazardous area information retrieval system comprising: a processor configured to allocate an identification to one or more components of the hazardous area in the engineering / design phase of designing of a plant comprising a hazardous area: a data storage for recording information related to components, and for recording the identification against the information for each component; a tag applied to each component in the build phase of construction of the plant, the tag comprising an indicator of the identification of the component; a tag reader for reading the indicator of a selected component of the plant so as to determine the identification of the selected component in the operation phase of the plant; and the processor further configured to retrieve the recorded information about the selected component according to the determined identification of the component.

[00030] According to a fourth aspect of the invention there is provided computer program for a hazardous area information retrieval stored on computer readable media comprising instructions for controlling a computer to: allocate an identification to one or more components of the hazardous area in the engineering / design phase of designing of a plant comprising a hazardous area; record information related to each of the components; record the identification against the information for each component; record an identification of a tag applied to each component in the build phase of construction of the plant; receive the indicator of a selected component of the plant read from the tag so as to determine the identification of the selected component; and retrieve the recorded information about the component according to the determined identification of the selected component.

[00031] Various aspects or embodiments described herein can be practiced alone or combination with one or more of the other aspects / embodiments, as will be readily appreciated by those skilled in the relevant art. The various aspects can optionally be provided in combination with one or more of the optional features described in relation to the other principal aspects. Furthermore, optional features described in relation to one example (or embodiment) can optionally be combined alone or together with other features in different examples or embodiments.

[00032] For the purposes of summarising the aspects, certain advantages and novel features have been described herein above. It is to be understood, however, that not necessarily all such advantages may be achieved in accordance with any particular embodiment or carried out in a manner that achieves or optimises one advantage or group of advantages as taught herein without necessarily achieving other advantages as may be taught or suggested herein. Description of Drawings

[00033] In order to provide a better understanding of the invention, embodiments are described with reference to the accompanying drawings, in which: Figure 1 is a lock diagram schematically showing a plant according to an embodiment of the present invention; Figure 2 is a flowchart showing steps in a method of accessing hazard information according to an embodiment of the invention: Figure 3 is a block diagram of a system for accessing hazard information according to an embodiment of the invention.

[00034] In the figures, like elements are referred to by like numerals throughout the views provided. The skilled reader will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and / or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to facilitate an understanding of the various embodiments exemplifying the principles described herein. Also, common but well understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted to provide a less obstructed view of these various embodiments. It will also be understood that the terms and expressions used herein adopt the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.

[00035] It should be noted that the figures are schematic only and the location and disposition of the components can vary according to the arrangements of the embodiment(s) as well as of the particular applications of such embodiment(s).

[00036] Specifically, reference to positional descriptions, such as ‘lower’ and ‘upper’, and associated forms such as ‘uppermost’ and ‘lowermost’, are to be taken in context of the embodiments shown in the figures, and are not to be taken as limiting the scope of the principles described herein to the literal interpretation of the term, but rather as would be understood by the skilled reader.

[00037] Embodiments described herein may include one or more range of values (eg. size, displacement and field strength etc). A range of values will be understood to include all values within the range, including the values defining the range, and values adjacent to the range which lead to the same or substantially the same outcome as the values immediately adjacent to that value which defines the boundary to the range.

[00038] Other definitions for selected terms used herein may be found within the detailed description and apply throughout. Unless otherwise defined, all other scientific and technical terms used herein have the same meaning as commonly understood to one of ordinary skill in the art to which the embodiment(s) relate. Detailed Description of Embodiments of the Invention

[00039] The words used in the specification are words of description rather than limitation, and it is to be understood that various changes may be made without departing from the spirit and scope of any aspect of the invention. Those skilled in the art will readily appreciate that a wide variety of modifications, alterations, and combinations can be made with respect to the above described embodiments without departing from the spirit and scope of any aspect of the invention, and that such modifications, alterations, and combinations are to be viewed as falling within the ambit of the inventive concept.

[00040] Throughout the specification and the claims that follow, unless the context requires otherwise, the word “comprise” or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

[00041] Furthermore, throughout the specification and the claims that follow, unless the context requires otherwise, the word “include” or variations such as “includes” or “including”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

[00042] Referring to Figure 1, there is shown a plant 10, which processes a raw material(s) 12 into a product(s) 14. The plant 10 comprises an input stage 20, a processing stage 22 and an output stage 24. The input stage 20 has one or more components 30 which receive the input raw material(s) 12. The processing stage 22 has one or more components 40 that process the raw material into the product. The output stage 24 has one or more components 50 that provide the processed input 12 as one or more products 14. One or more of the raw material(s), or the products(s) 14, or interim products may be hazardous, for example electricity, fuel, flammable, combustible or explosive material, corrosive material, acid, oxidising agents, chemicals, radioactive material, biohazards, or poison. Components 30, 40, 50 may operate with such hazardous materials and need to be in good working order, and meet regulatory and practical safety requirements.

[00043] The input stage 20, processing stage 22 and output stage 24 need to be designed / engineering (step 60 in Figure 2), built / constructed and tested (step 60 in Figure 2) before being put into operation (step 90 in Figure 2). In operation, the input stage 20, processing stage 22 and output stage 24 need to be monitored, maintained, repaired and upgraded, depend on the circumstances, for operation / from time to time, during operation.

[00044] Whilst described as components in the present application, the components may be systems, sub-systems, individual components of equipment and / or parts of the equipment with no through to complex hierarchy.

[00045] A significant requirement during operation is inspection of the components. Each component is provided with a tag ID1, ID2, ID3, ID4, ID5 and ID6. Preferably the tag is machine readable, such as being NFC, or RFID, bar code, QR code or the like.

[00046] In the engineering / design phase of designing 60 of a plant comprising a hazardous area, hazardous areas and the components therein need to be determined / specified 62. Each is allocated an identification 64. For example, a flammable gas may be received as an input, stored and used as a fuel in the process. The storage area comprising gas storage tanks will be designated as a hazardous area. The pipes, valves the tanks etc are components in the hazardous area that all need to be in good working order. Each is identified in the design and allocated an identification (eg. a number) and each component is of a component type, for example: pipe, valve, etc.

[00047] According to the present invention as these are designed the identification of the components are recorded 66 along with information about the components. In an embodiment only electrical / instrumentation or mechanically rotating parts need to be captured, such as for Electrical Equipment in Hazardous Areas (EEHA) compliance (this includes valve actuators etc.).

[00048] In an embodiment, an efficient way to record this information is to record some of the information common to components of each type and then record that the individual component is of that type. Then information specific to the individual component can be recorded against the component type, for example, the component's location in the plant.

[00049] In the build phase of construction of the plant 70, each component 30, 40, 50 is installed 72 and tagged 74 with an indicator ID1, ID2, ID3, ID4, ID5 and ID6 of the identification of the component.

[00050] In an embodiment relevant information not obtained during design, but obtained during construction is available, particularly if relevant to the later inspection of the component. For example, a part serial number of the installed component is recorded. This information is recorded 76 against the identification of the component. Further testing and verification of the component's operation and suitability occurs. Information is derived 78 from this. This information and certification of the component's correct installation and working is recorded 80 against the component's identification.

[00051] In the operation phase 90 of the plant, each component is inspected 92 to ensure it is working correctly and is good working order. In some cases, repair / maintenance 96 is required. Information about this (eg replacement of a part) is recorded 98 against the component identification. During inspection, repair / maintenance information recorded about the component may be retrieved by scanning the tag of the competent and calling up this information 94. For example, is a part is replaced, then the new part's serial number can be recorded against the component's identification.

[00052] This wealth of information from design, installation / build or history of the component has previously not been available, at least not in an automatically retrievable manner, and typically some of these records are on paper, off-site, lost, or not available for many reasons.

[00053] During documentation of the inspection this information can be used to pre- populate sections of the documentation, thus saving considerable time and effort, as well as, ensuring accuracy by eliminating the possibility of introduced error.

[00054] The present invention is not in this information but rather a process of building accessibility to the information into infrastructure and the infrastructure to organise and allow access to this information in a centralised and integrated manner. This infrastructure can achieve real time access to vast amounts of information in a structured and organised manner because of its systematic approach to, and apparatus for capture of, the information, over time, from different sources at different stages from design / engineering, build and operation of the plant, organisation of storage of the information and the physical linkage of the information to each component of the plant by means of the indicator / tag applied to the component, across its lifecycle. Further, analysis on the information can occur, including extracting information according to search criteria or groupings / relationships or timeframes that are only possible due to this infrastructure which allows for collection and organisation of this information. This can address a problem with current information replacing historic information, as currently occurs. Furthermore, cross plant analysis on the information can also occur.

[00055] Referring to Figure 3, a system 100 for implementing the present invention comprises an input 102 (such as for example a human interface such as a keyboard 104 and mouse, or a tag (ID) reader 106). The input 102 passes data these input devices to a processor 102, which organises the data and stores it in a data storage device 122, such as a hard disk drive, or cloud storage. When information is received via the input 102, the processor 120 is configured to identify the information to retrieve from the storage 122 and to retrieve it, and then to provide this retrieved information to a user via an output 124, such as a display.

[00056] The processor 120 may be implemented as electronic circuitry but may also conveniently be implemented by executing instructions of a computer program which configures the processor to operate so as to be configured as / to perform aspects of the invention described herein. EXAMPLE IMPLEMENTATION

[00057] The present invention can provide an EEHA Classification, Engineering / Design, and post installation Inspection documentation and dataset for a client as a Hazardous Area Verification Dossier. Engineering Hazardous Area Classification (HAC)

[00058] A drawing (2D or 3D model) of a hazardous area can be imported or exported to a Design Drafting software package.

[00059] The hazardous area can be classified and the classification recorded as A1 / A2 / A3 / B1 / B2 / B3, Zone 0, 1, 2, 21, 22, etc. For example, the type of hazardous material and operating conditions (eg pressure and temperature), potential sources of release, types of line (pipe) etc. For example, each flange (or release type) is provided with a field for the classification and this recorded.

[00060] The classification report should conform to a predefined structure. Engineering & Design

[00061] Engineering such as Intrinsic Safety Calculations, Heat Dissipation Calculations, Conformity Assessment Documents, Fitness for Purpose reports are developed within the software package, again within predefined formats and datafields which the user will need to provide, and the formula to be run in the back end of the software / site / database and then the end output. Prepopulated ITR’s for Constructors

[00062] Each EEHA tag shall have all engineering inputs completed during the engineering phase, this data (to a degree) shall be pre-populated on Inspection and Test Reports. There may be 42 fields per tag (or more). Tags can be located within a Plant Area / System / Subsystem.

[00063] All documents can be available within the HAVD and can be referenced against tags as appropriate for the inspection process, indeed the document if relevant can be attached to the relevant ITR.

[00064] Tags will be generated in one of two ways: Engineering team developed and direct input to the system. Vendor data during engineering and then confirmed post inspection. Data Entry

[00065] There may be quite a few data sets that need to be entered into the software database, these are listed below with entry / interface options. Refer to the tag dataset spreadsheet: 3D models referenced within a tag's dataset such that the model number and revision is clearly identifiable; 2D Models numbered and entered into the tag's dataset; Computer Flow Dynamic model — these just need to be entered in as a reference in a tag's dataset. Vendor Data by direct entry —the EEHA tag dataset Certificate of Conformity — can be a hyperlink to the actual certificate, suggest this is entered as the certificate number such as IECEx TSA 09.3467 Issue 2. Conformity Assessment Document — as above for certificate. The IEC Ex document number will be used for mate we use is: (i) Look like this 00x0yz-aaa-bb-ccc (ii) Client number — 00x (iii) Project number — Oyz (iv) Document type — aaa, could be REP for report, CAL for Calculation... (v) Discipline — bb, EL electrical, PR process, IN instrumentation... (vi) Doc number of that exact type — ccc. Field work - Construction & inspection

[00066] ITR’s will be generated for each EEHA tag as listed in the engineering data. Certain data shall be pre-populated and made available to the inspector, however, some data even if in the database will not be available to the inspector — such as serial numbers etc.

[00067] ITR's can either be printed and completed via field tablet with data direct uploaded to the database (if wifi connectivity available) or tablets can be synchronised to the database on return from the field. Engineering Control or locking of Data — Toll Gate

[00068] This data needs an engineering freeze prior to being able to go past this point. This may use: a) Tick boxes to control this b) authority to tick it or bypass it given the commercial scheme between a: (i) Design and Construct Contractor or (ii) an EPCM Engineering house and a Construction / Inspection Contractor. Completion of ITRs

[00069] An ITR for a tag shall have as attachments all certifying information required to complete the inspection, this may include: Ex certificate of conformity (IECEx or ANZEx) Conformity assessment document (CAD) for non IECEx or ANZEx equipment. CAD's shall also include the non-compliant certificate. IS entity calculations — including the certificates for barrier and “as installed cable schedule lengths”.

[00070] When data is returned from the field those fields are then locked from further engineering input unless: (i) Subject to Technical Query (TQ) post inspection and the compliant TQ response requires further engineering. (ii) The equipment is replaced.

[00071] Field Inspectors will have the ability to generate a TQ from their inspection of a device which must be completed, answered satisfactorily prior to the completion of that inspection. This may result in further engineering, so this is a loop back to opening data- fields for engineering to modify. Dossier Database & Delivery General

[00072] The database shall be used as the repository of knowledge for the HAVD, specifically all the data associated with engineering and inspection of equipment. The data shall be presented in a pre-determined format completed with section headings and project introductions and pre-ambles. ITRs

[00073] Examples of the following documents shall be provided to properly understand the scope of each: Classification report — which will consist of a document output but also refer to a Schedule of Release Table. HAVD — HAVD Data Entry dataset Conformity Assessment Document CAD - Fitness For Purpose Statement FFP IS Calc Ex e heat calc Simple Apparatus Assessment, (which is specifically required for devices in an IS circuit that have no inductance or capacitance but may cause a spark by action such as an opening / closing contact of a switch). Personnel Competency and Signoff Acceptance

[00074] Personnel shall have a profile loaded to the database which shall include their: Signature sample. A grade licence # for inspectors CPEnNg # for engineers (if held). Record of EEHA competencies — this will dictate ability to sign certain documents. Record of pre-requisite qualifications.

[00075] Inspection and Engineering documents have an online signature and review section, ability to review or even produce documents shall be controlled by a person's “personal details and competency profile”. There may be the following review / signoff fields: Originator / EEHA Inspector. Checker (Approver) / EEHA Supervisor. Construction / Commissioning Superintendent Acceptance Client Acceptance

[00076] A matrix can be provided during the detailed phase indicating who can sign of what based on their competencies. Program Presentation — Operator Interface General

[00077] Desktop Icon is clicked to start the software. Software is applicable to oil and gas, organic food processing and mining. Initial Login

[00078] A) Software opens up to the entry portal — requests: (i) Company Code — each company will have paid for a specific module access license (ii) Username (iii) Password B) Entry Project Page. The login takes you to a project page where there is a company title page and drop down menu for Project Selection. Only projects the company has registered are shown. Depending on the Company / Username / Project will depend on what User Type is available — this may differ across projects for the same company for the same user. C) User Types User Types EEHA Admin - Master

[00079] This person is the Master for this project, they may be for the companies entire sweet of projects but not necessarily. Roles of the EEHA Admin — Master: Sets up ALL other users for a project — this may include transferring across users from other projects from the company. Uploads all user competencies and in consultation with the EEHA Lead Engineer sets signature permissions. Responsible for quarantining EEHA data once inspected. Responsible for uploading all data regardless of the source. Responsible for auditing EEHA data within a project, as in ensuring its veracity. Has all access rights detailed below for other users. Master also develops and monitors EEHA system completion reporting. Reports to the EEHA Lead Engineer. EEHA Lead Engineer

[00080] This person has the second highest level of access to functionality, overwriting quarantined data is the only function that cannot be completed by this person. Roles include: Responsible for Leading the entire EEHA implementation. Reports to the EEHA Program Manager. Access defaults to EEHA Admin — Master in the absence of the actual Master (on R&R). Can authorise / implement additional sections to standard document templates. Can complete all engineering functions, can sign all engineering documents and inspections. Monitors EEHA system completion reporting. Can approve ITRs. EEHA Superintendent

[00081] This person is responsible for ensuring consistency in inspections and ensuring competency of inspectors. Roles: Can sign all inspections. Can review and engineering documentation and provide comments but NOT sign and accept unless the competencies are loaded to the user profile. Organises EEHA inspectors and supervisors for system completion. This person reports to the EEHA Lead Engineer, there may be two or even three superintendents on a large project. Defines the ITR pre-population data, this is to ensure maximum efficiency of inspection without compromising data collection integrity. Monitors EEHA system completion reporting. Can approve ITRs. EEHA Admin —- Data Entry

[00082] This person is responsible for bulk data entry. Roles can be delegated by the Master.

[00083] Essentially this role is in support of the master and there may be two or three in this role. EEHA Inspector & Supervisor

[00084] This person completes inspections in the field, supervisor also does this but responsible for coordinating inspection teams. Roles: Completes field inspections, this may be Vendor / Modyard / Site. Inspections are completed in a tablet, the ITR’s on the table have ALL associated engineering data and certificates selectable such that they can be reviewed in the field. Identifies defective equipment and reports this on the ITR — this is then identified within the system for corrective action. Signs and accepts properly installed EEHA equipment.

[00085] Supervisor Accepts ITRs approved by inspectors. Raises technical concerns with the superintendent for review by engineering. Client Approver

[00086] Client Approver User Types are utilised as follows: For approving documents being developed in the engineering phase. For approving documents in the construction phase resulting from emergent engineering requirements. Approving and accepting completed EEHA ITRs. Approving and accepting system EEHA completion. Approving and accepting HAVD handover.

[00087] Client approvers cannot develop engineering documents nor complete EEHA inspections. This is an approval function only.

[00088] HAVD approved in this fashion may be transferred to an “Operations” project. Client Approvers access permissions may change during this transfer, the new permissions will be assigned by the EEHA Admin — Master. Operations & EEHA Maintenance Specialist

[00089] Operations will required All User Types mentioned above. In addition there shall be a EEHA Maintenance Specialist & a Contractor Portal. Contractor Portal

[00090] This portal is available under the Operations license, the portal ONLY allows engineering documentation to be loaded. This portal allows for Inspector User types such that inspections can be completed within the software by Tablet. EEHA Maintenance Specialist

[00091] The maintenance specialist role is to manage the EEHA maintenance campaign through operations, planned shutdowns and unplanned shutdown response. The Role includes: Develop and implement the EEHA maintenance ruleset. Manage the Maintenance Management System (SAP) interface. Schedule EEHA maintenance activities and monitor the maintenance trends of equipment by area, system and subsystem. User Interfaces

[00092] After logging in each User Type has a slightly different view experience. All projects, the view states the asset name and “Project” such as ..... XNAMEX LNG - Project Admin Interface

[00093] There are four views for standard admin people: 1. Engineering View — see below. 2. Personnel Management view. 3. Inspector View 4. Auditing view.

[00094] The admin person needs to select which view to use. Auditing View

[00095] This view essentially looks like the data entry spreadsheet with all fields searchable. What is clear in this view is data is indicated by colour as to what state it is in: Engineering Preliminary (loaded for information or review) — backlit Pale BLUE. Engineering Final (handed over IFC) — backlit BLUE. Admin Quarantined data — data itself is RED. TAGS, Not inspected — backlit GREY. Inspected but not passed — backlit PINK. Inspected Partial — backlit AMBER. Inspection COMPLETE — backlit GREEN. Personnel Management View

[00096] This view allows for user management. This view shows: All people currently loaded on the system for that project, their competencies and signature permissions. Against each person is a sample signature. Against each person is a hyperlink to pdf's of their competencies. Each person is assigned a User Type.

[00097] The view has add / remove / edit buttons in order to add / remove or edit a persons profile in the event of changing circumstances. Admin Master

[00098] The admin master, unless the ability is delegate, is the only person who can quarantine data. Engineering Interface

[00099] The engineering view opens up on login. There are two selections: 1. Engineering Document Development view. 2. Tag / Data view Tag Data View [000100] This view has multiple search boxes where you can either use dropdown selection or type in with % as wildcard, these are the boxes: (i) Tag number (ii) System Number (iii) Subsystem number (iv) Certificate of conformity (v) Protection technique (vi) CAD document number (vii) FFP document number (vii) IS Calc Number (ix) Ex e Calc number (x) Serial number (xi) Model number (xii) HA Zone (xiii) Vendor Inspected (xiv) Modyard inspected (xv) Inspection Partial (xvi) Inspection but not passed (xvii) Tag NOT inspected (xviii) Inspection Complete [000101] The engineer can export search results to excel spreadsheets if required. Search results are displayed in a non editable dataset — the dataset allows further search interrogation by providing minimised search boxes as listed above so the search can be refined. [000102] From the colour coding of dataset display status of tags can be determined. Engineering Document View [000103] In this view the engineer can: (i) Create engineering documents. (ii) Search, edit and review engineering documents. (iii) Interrogate specific tags (or tag sets with common model numbers) and documentation associated with it. [000104] The view provides searchable boxes (with dropdowns) to search for documents for approval; / review editing. When a document is selected the document view opens up which is displayed as a series of boxes for data entry — these boxes appear as per the document TEMPLATE format already provided. [000105] When creating a document from scratch the steps are: 1. This is done within the project space. 2. Select document type. 3. Select either a tag number OR certificate number. 4. Generate document number. 5. Complete the document by entering data in the required fields this may be: (i) Photo's of name plates. (ii) Certificates (iii) Testing body quality documentation. (iv) Is very dependant on the document. Inspection Interface [000106] The interface comprises tags that have been assigned to them to inspect. On selecting a tag they are presented with an ITR for that tag. They complete check boxes and write information in that is requested / required. All associated documents are hyperlinked within the ITR for them to load and review on the tablet as they inspect the equipment. [000107] On completing the inspection they select sign and the ITR is completed with their signature and sent to the Supervisor for review and approval. Supervisor [000108] The supervisor can assign tags / subsystems to an inspector to complete. Supervisors also review and approve inspections. Supervisors can also enter technical queries in relation to a tag and or a supporting document. Client Interface [000109] Is essentially a review and approval interface for all engineering documents and inspection ITRs. Monitors EEHA system completion reporting. Operations Interface [000110] This view states the asset name and “Operations” such as ....XNAMEX LNG - Operations [000111] The HAVD from a project is handed over to Operations they may call it something other than what the engineer / construction contractors called it. Operations view has all the other views as operations essentially need to do all of those tasks. Example implementation on a Plant [000112] Tag counts for a large LNG projects can exceed 100,000, with each tag needing 42-60 unique data fields completed for each tag. A data field could be as simple as a serial number but as complex as a calculation or a Fitness For Purpose statement or CAD. The invention can manage all of this data and potentially across other projects. This allows for, for example, a recalled component to be traced to location and also its replacement recorded without loss of the historic data. [000113] Further a design flaw in one plant can be assessed and acted on in another plant by access to design / engineering data tied to a component which as its tag scanned in the field. [000114] This data is able to be tied to component through Engineering & Design, then Construction & Commissioning and finally for 25+ years of operation, which previously has not been possible. Further personnel competencies to complete tasks can also be managed. [000115] Historically, prior to this invention, once a tag is inspected, “engineered” data is overwritten / modified, sometimes by personnel not even on site. However, in the present invention the history is stored with “As-inspected” information. This might for example detect at inspection substitution of a component with one that was not in accordance with design and that might otherwise be overlooked but for this invention enabling this to be identified. Updated data (say to 10,0000 components) is appended to historic data with a time stamp and tag information ties this to the physical component so that (say 6000 of the components that have been inspected) do not have to be re-inspected or have the inspection data lost, as currently happens. Technical Design Specification [000116] A technical specification for the design of a software implementation of an embodiment of the invention is annexed hereto. [000117] The skilled reader would readily appreciate the nature of the materials appropriate for making the components of the embodiments of the arrangements described herein. Modifications and variations may be made to the present invention without departing from the intended concept. [000118] Future patent applications maybe filed in Australia or overseas on the basis of, or claiming priority from, the present application. It is to be understood that the following claims are provided by way of example only and are not intended to limit the scope of what may be claimed in any such future application. Features may be added to or omitted from the provisional claims at a later date so as to further define or re-define the invention or inventions. Annexure Example Software Implementation 1 Overview This document is created to detail the technical design and specifications of the Total-Ex project in cooperation with Imperium. The specification document created will serve as a basis to develop a working Stage | application of the Total-Ex project. The scope specifies the data storage, workflow and functional requirements for the Total-Ex application. 1.2 Introduction Imperium are an electrical engineering company, working on large scale resources (mining, oil and gas), military and government projects. Their focus is on hazardous sites involving dangerous and explosive chemicals etc. The process, administration and documentation around safety compliance on these projects is onerous, and rarely, if ever done properly. Imperium envisage a platform for documentation and approval of Electrical Equipment for Hazardous Areas. The platform will simplify and structure the process of documenting data as well as centralizing the storage of associated information. Stage | of the project will cover the Engineering Stage of a project. In the future, extension of the application to cover Construction and Operational Phases is envisaged. Working name of the application is Total-Ex. 1.4 General requirements 1.4.1 Core Data Integrity — data that is engineering complete or inspection complete cannot be overwritten without some control in place. User Competencies — provide evidence that the person has competence to complete tasks for the EEHA workflow. Competencies are linked to their ability to sign things off. Tag Generation and Tag Management — everything equipment related in EEHA can be referenced in a tag. 1.4.2 Secondary Secure and stable infrastructure Multi-level user and permission system Capture engineering certifications, education level within an operator profile Complete engineering workflow © Creation of engineering projects on a client basis © Log and track engineering data per client © Enter necessary additional information based on tag information (e.g. classifications based on colour) o Knowing if a tagged item requires EEHA certification o complete engineering documents within the package such that they are correctly tag associated - e.g. CADs / FFPs / SAAs o Perform Calculations to mark project / tags as engineering conform based on reference data o Sign off process Setup to allow to on-sell the application to other companies Work on desktop and tablet devices 3 Management Areas and Workflow There will be two types of areas for management of the Total-Ex application. The Frontend Interface will be used by users with the appropriate permission to manage engineering projects within the defined Project Workflow and to manage users within an account. The Admin interface will be accessible to IMPERIUM users only to manage core project data and permissions including Accounts and settings, that are not part of the Frontend Interface 3.2 Proposed Total-Ex Workflow Total-Ex Admin creates an account for an engineering company that will use Total-Ex to process EEHA on behalf of a client. o Creates & defines the account information for the engineering company © Creates & defines the Admin user(s) of the account User activates account Defines password Logs into the application Create Project © Admin Account user creates Project Defines the project base data including, tag names file-names convention. o Admin Account User defines / creates the Project Users Defines user permissions and groups. Defines the required documentation required to upload. (Vendor, Inspector, Installers) Uploads the Users documents Activates the Users account Email sent to Project user to activate account, if they had not have account © Defines password © Logs into the application If they already have a login, email send they have been added to project Engineering o Competent user creates the SoRT (schedule of release table) Defines the systems; Sub-systems; Vendor packages used in the project Adds details into the sort to assist with the Tagging workflow Uploads documents for each system; sub-system; vendor package Assigns documents per line item for Sign off SORT Sign off process applies. © Competent user creates Classification Report Document Approval process applies © Competent User uploads Project documents Document Approval process applies 0 Create Tags list / HAVD list Competent user creates the Tag list Uploads CSV that populates the Tag list © The data is matched to the system; sub-system; vendor package by a Tag No / Line No / Item No / Building No which will act as a lookup value. Data from the SoRT table will be populated into the Tag based on the Tag No / Line No / Item No / Building No Updates the Tag list row by row to resolve any issues raised in the logic i.e. Must be |IECEx or ANZEx if not add CAD Updates the Tag list row by row to resolve any flagged rules based on site rules. Tag list approval process applies Each line item is marked as ‘Engineering complete’ in order to complete Engineering data of the Tag List. (Note: Documents require separate approval beforehand) Client User / Acting client user approves the Tag list Mark project as Engineering complete / lock Engineering data Inspection Hand over to inspection users oO Enter tag inspection data Check data and upload additional documents Document sign off process applies Tag sign off process applies Mark Project as HAVD complete Export HAVD 3.3 Project Workflow An Engineering Project follows the following workflow from initial creation to quarantining the project. All views and interactions that are part of the Project Workflow will be available using the Frontend interface. Details are described in the relevant section of this scope. 4 Front end user interface 4.1 Authentication and account management 4.1.1 Login A view with an authentication form consisting of an email address and password field and a link to allow the user to reset their password if required. 4.1.2 logout A view that logs the user out of the application when visited. 4.1.3 Password reset A collection of views to allow the user to: Request an email containing a unique ‘password reset’ URL. Change their password after visiting said URL. 4.1.4 Change password Allow a logged-in user to change their password if they know their existing password. 4.1.5 Set Password Newly added users shall receive an email containing a unique ‘password reset’ URL link. The link will redirect the user to a password setting view, where the user is prompted to create a password. On completion the user is redirected to the Login Page. 4.2 Navigation Main Navigation Project List My Account Account (depending on permission) Footer Navigation T&C Privacy Policy Contact Imperium 4.3 Project List View Once logged in a user will be redirected to the Project List view. The list view shows a list of Projects available to be viewed by the logged-in user according to their accessible projects as per allocated permissions. Global Action Button will be visible based on users’ permissions. 4.31.1 Users with only one accessible project should be automatically redirected to that projects detail view instead of being shown a list. Mockup 4.4 Create an Engineering Project A view to allow the user to create a new Engineering project and enter base project data. 4.4.2 Project Detail Page / Overview A view that shows project base data and links to additional data within an engineering project. Selecting a link should navigate the user to an appropriate view from where to add, edit and view additional project data. Unavailable links will be greyed out. Unavailability is defined by the project status. Based on permissions links will not be displayed. The Detail Page contains the following information appropriate to the user's permission and status of the project: Project Base Data Project Status Link to Manage / view base data Link to Manage Users Link to manage SoRT Link to manage Tags Link to manage Documents Link Sign off Management Action - Buttons Delete Project (Only Total-Ex Admin) Potentially add a link to upload ‘classification’ PDF document An Engineering Project can only be removed if no Engineering Project data has been entered apart from the base data. Project Statuses The following statuses have been identified: Engineering Phase Classification Preliminary (SoRT in development / not approved) o User unavailable to add tag data Classification approved 0 SoRT and Classification Report in “Issue to Use” - Rev 0 o Users are now allowed to create tags o Only Engineering relevant fields listed in tag list Detailed Eng o User has started to work on Tags (first tag data entered) Eng Approved o All Documents / Tag / SoRT / Classification is client approved o Project is locked All Engineering Project data locked from editing Inspection Phase Execution o Additional tag fields added to tag list © Inspection Tag fields can be edited © Inspection Documents can be created HAVD complete Action Buttons Lock project o becomes available once all Sign offs are complete and client has approved project © Project Status is “Eng Approved” once locked Unlock project © Available on a “Locked Project” © Available only to Admin Master Mark Project as “in Construction” 0 Moves project status to “Execution” o Engineering data is still locked. 4.5 Project Users List A view showing a list of project users. With selecting a user the detail page is opened. 4.6 Add a Project User A view to add a project user to the project. Core User data The following data will be added per user Title First Name Last Name Organisation ‘Working Title Role Email Mobile Landline User Group Users Signature Certifications and Competencies Certifications and competencies shall be defined on a user. Full details have not been provided at this stage. 4.6.1 Permissions Permissions of a user are defined by a user group and by their competencies. A user group will be manually allocated to the project user by the Master Admin. The competency permissions should be automatically applied, if feasible. The matrix for all certifications and competencies has not been specified at this stage. 5 Engineering Phase 5.2 SoRT List View The SoRT list view shows one or more tables of SoRT data according to their type (Gas & inflammable liquids, Dust, Pipeline, Ventilation, Plant Building). If several Revisions available the user will be able to view all revisions. Previous revisions are locked down from editing. Only a new revision can be edited. Details on Revision handling are outlined within the sign off section of this document. A link to “Edit SORT” will be available that allows the user to edit the SoRT types displayed. If no data record has been created the view will be empty and a link displayed to ‘Create a SoRT’. 5.2.1 Table Types Hazardous Gas & Inflammable Material List Hazardous Plant Building Area List Global and instance action button will be visible based on user permissions. 5.3 Create a SORT A view to allow the user to select the types (gas & inflammable liquids, dust, etc) as the basis to create the SoRT. On Submission a REV A of the SoRT is created populating the appropriate tables. 5.4 Populating SORT Type Tables The user will be able to add and edit items from the SoRT Type tables given the appropriate permissions. When adding or editing a SoRT list item, aforementioned fields based on types will be available. All fields will need to be entered for each data table. Referenced Document numbers will automatically create an empty Document item. Document fields will link to the Document list. The user can save the entry or cancel. A SoRT Table entry can only be removed if no associated tag data has been entered. Mark as Complete If a SoRT is finalised, it is “Marked as Complete” and locked. At this stage the Approval and Revision process starts which is outlined in the Sign-Off Section. The Sign - Off process needs to reach the REVO Stage before a tag list can be created. Alternatively, a user can tick the “SoRT Issue to Use approved” checkbox and upload the latest client approved SoRT document. If ticked, and an approved classification report has been provided, a tag list can be entered. 5.4.1 CSV Upload of SORT A SoRT can be uploaded via CSV. All required fields and heading for all items need to be defined. When uploading the data is split into relevant section. A CSV re-upload will override existing data completely. The user will be presented with a warning that they may lose data if they proceed. Only the Admin Master can reupload a file. No CSV upload possible when approval process underway. 5.5 Uploading SoRT Documents Handling as per Tag Documents. Please see Workflow Diagrams https: / / projects.invisionapp.com / share / RTRSPEVYJKA# / screens / 364398338 Uploads can then be performed from the SoRT Table OR the Document list. 5.6 Classification Report A classification Report will need to be uploaded into the Application. The classification report in combination with the SoRT forms the 1 Step of the Engineering phase. This could be for this DOC, FFP, SAA, CAD documents If both are completed and ‘Issued for Use”, Tag creation can commence. A Classification report is a Document in this application that will follow the typical documentation revision and sign off process. See Document Sign Off and Document Revisions. 5.6.1 Classification Report - Override of SORT A classification report could contain different area classifications than the SoRT. If it does, the values in the classification report will be stricter and are area based. If values differ, the user needs to create a Classification Override via a form. This override will then apply when validating tag data against the SoRT. For each area defined in the SoRT that a user wishes to override, all fields will need to be defined. Specific fields of override will need to be specified. 5.7 Tag List A view showing a table of all tags including information on tag, document and sign off status as well as tag conformity. If no tag data has been entered the Tag list will be empty. Links to Upload a Tag and to manually enter a tag will be available at all times. The user can filter the tag list by any field. The user can activate the filters that seem appropriate for filtering the table. In addition, filters for Tag, Document, Sign Off and Conformity Status will be available. The Tag Fields displayed are dependent on the Status of the project. In the Engineering Phase only identified Tags associated with ‘Engineering’ and ‘Operation’ will display. Appendix C outlines which Tag Fields are available, outlining the associated field type. List Details | Fields | Field Name As per Appendix C Tag Status Document Status Sign Off Status Sign Off Comment Tag Conformity | Sort by | Tag ID | Filters | Based on tag fields configurable by user | In addition Document status Tag Signed off / not signed off Tag Conform / not conform | Multiple Select | Label | Tag Conformity Search | Search for: | (i) Tag ID Sign off Status Signed off Not signed off This is a first sign off stage. Details to tag sign off are outlined in the Sign Off section of this document. Document Status Provided Not Provided Required documents will be determined based on the provided tag rules. For documents where no rules have been provided a check cannot be performed. Exceptions will need to be handled manually by the user. Tag Conformity Tag conform Tag not conform This is a second sign off stage. Details to tag sign off are outlined in the Sign Off section of this document. Tag data can be deleted from the table. Documents associated with the tag will not be removed, however the tag association to the document will be removed. 5.8 Add a Tag Tags can be added using a CSV Upload functionality or via adding the data manually. 5.8.1 Manual Tag Entry A view that allows the user to add a tag to the tag list. 5.8.2 Upload A view that allows the user to select a CSV file for upload. The tags will be populated in the tag list after upload. If a line item in the upload fails, the remaining tag data will be uploaded and the user will receive information which lines have failed uploading. A new upload will generally only add tag data, and never override existing tag data. Data is matched based on Tag ID. If Tag ID does not match, data will be added. Exception is uploads performed by the Admin Master that can decide to override existing table. If ticked the tag table is emptied on upload and the new table populated. NOTE: Matching of data can always lead to a convoluted list if the user uploading the list has a typo in all tag IDs. 5.9 Creating / Editing Documents from TAG List Referenced Document numbers in the tag list will automatically create an empty Document item. Document fields will link to the Document list to be edited or can be viewed directly (if document format allows for it, the latest revision of document) via a view link. The user can also create a document from within the tag list. The workflow is outlined below. 5.10 Calculations on Tags Depending on tag values, a specific calculation will be performed on the tag. The application shall have the capacity to perform the following calculations: Heat dissipation calculation for tags with ‘Exdesign Technique’ is Ex “e” IS Entity calculation is required for tags with ‘Exdesign Technique’ is Ex “i” Other calculations are not part of the application and will be performed externally. The calculation will be uploaded as a document only. For the heat and IS Entity calculation the user will need to fill in a separate form connected to a tag / tags. Based on the data entered the calculation is run and defines whether the data in conform or not. If not conform, data can be edited and the calculation rerun until the tag is conform. NOTE: One calculation may be applicable to more than one tag. The calculation should be tag associated. Details and References to the calculation are in Appendix D of this document. Create Heat Dissipation Calculation The user will enter all fields into a from that are required to perform this calculation. Fields to be specified. Create IS Entity Calculation Fields are depending on the Loop Setup. There may be 0, 1 or 2 junction boxes in between an apparatus and another device connected each via cables. The user shall be able to define how many junction boxes are used and how many cables. Data for apparatus (Output) and input device need to be defined as well as junction boxes, if applicable, and cables. According to this additional fields will need to be entered for every additional junction box and the cables that run between junction boxes. The calculation varies. Apparatus (Output) MANUFACTURER SERIES MODEL Project Cable Code or Part No. CERTIFICATION Type of Protection Ambient Temperature Range Min Ambient Temperature Range Max EARTHING REQUIREMENTS SIMPLE APPARATUS (YES / NO) - not required Maximum output voltage Maximum output current Maximum output power Entity parameters applied below are for Maximum external capacitance Maximum external inductance or Maximum external Lto R ratio Current / Voltage characteristic Lumped internal capacitance Lumped internal inductance Cable mutual capacitance Cable inductance Device (Input) MANUFACTURER SERIES MODEL Project Cable Code or Part No. CERTIFICATION Type of Protection Ambient Temperature Range Min Ambient Temperature Range Max EARTHING REQUIREMENTS SIMPLE APPARATUS (YES / NO) © Maximum input voltage © Maximum input current © Maximum input power © Maximum internal capacitance o Effective internal capacitance ©o Maximum internal inductance © Maximum exterior inductance Or Maximum internal L to R ratio © Lumped capacitance or inductance (YES / NO) For each junction box (0-2) MANUFACTURER SERIES MODEL Project Cable Code or Part No. CERTIFICATION Type of Protection Ambient Temperature Range Min Ambient Temperature Range Max EARTHING REQUIREMENTS SIMPLE APPARATUS (YES / NO) For each cable (1-3) MANUFACTURER SERIES MODEL Project Cable Code or Part No. Cable mutual capacitance Cable inductance Cable conductor resistance Cable inductance to resistance ratio Cable length km After entering the data field the user runs the calculation. Data Output INTRINSIC SAFETY LOOP VERIFICATION Each item displayed as ok / not okay / na 1) Voltage Test Uo<=Ui 2) Current Test lo <= li 3) Power Test Po <= Pi 4) Capacitance Test I Ccable + Ci< Co 5) Inductance Test I Lcable + Li< Lo 6) External L / R ratio Test Verified Intrinsically Safe: Yes / No Type of Protection for this System: Ex ib IIB If required, further specifications will be done during project implementation. 5.10.1.1 Sign off Calculations on Tags A Completed calculation will require approval. Please refer to the Sign Off Section of this document. 5.10.2Tag Sign Off Details on Sign Off are included in the Sign Off Section in this document. 5.11 Document List A view showing a list of all Documents of an Engineering Project. Selecting an individual Document should navigate the user to the Document Details. Quick link on the Document should open the uploaded document. Documents will be stored with a Document type making it easy for the user to find relevant documents. Documents can be associated to a Tag, SoRT or the project as a whole Revisions of documents will be stored. Tags will need to be a hyperlink to the most recent certificate. The document list will have all revisions available to view. Automatic Creation When adding SoRT data or Tag data a document element is automatically created with the Document Type and Number and SoRT OR Tag associations according to the SoRT and TAG data, The document itself will then need to be uploaded. The process of creating or editing a tag document from the tag list page is outlined within the ‘Uploading TAG Documents’ section of this scope. 5.13 Document Approval Each document will need approval from at least two competent users assigned. The user views the document and can sign it off. Sign Off Date, Time and person will be recorded on the document. Detailed information is contained in the “Sign Off” section of this document. 5.14 Sign Offs Sign offs to SORT, Documents and Tags will be performed within the application. The workflow for the Sign Off will differ depending on the item to Sign Off. 5.14.1Sign Off SORT Once a SORT REV is ‘marked as complete’ it is ready for Sign Off. The SoRT Sign Offs follows a two step process including a different Revision process. SORT Engineer Approval The SoRT will be locked for editing. 2 competent users will sign off, the SoRT. An additional Checker may be involved, that can comment item, however cannot Sign Off. Only REV 0 (or following) is signed off by 2 competent engineers and the client. Each line item will need to be signed off separately. If a line item is not approved, the user will mark as ‘not approved’ and make a comment. The author will create a new Revision REV B with changed and ‘mark as complete’. All previously signed off items, will keep the ‘approved status’ and will not need to be approved again All changed items will need to be approved. All previously unapproved items will need to be approved. The process continues until all items of a REV have been approved by 2 competent users. If all line items are approved, the SoRT will be marked as “Issue for Use”, which automatically creates a copy of the latest approved SoRT and saves it as REV 0. REV 0 will need to be signed off. SoRT Client Approval Previously approved items by Engineer Approvers will be marked as approved in the REVO. The complete SoRT requires sign off by the client. If the SoRT is not approved, the client will mark as ‘not approved’ and make a comment. The Engineer can then create a REV 1, make changes and hand the changes over to the Engineers to sign off. NOTE: once a REVO and following has been submitted, no new Revision can be created if an Engineer does not approve. The REV1 will need to be altered within that Revision until it is ready for Client Sign Off again. Once a Revision is approved by 2 competent Engineers and the Client, the SoRT can be marked as complete. 5.14.2Sign Off Classification Report The Sign Off follows the same principle as the document sign off. However this sign off will need to be at a Stage REVO before Tag Creation can commence. 5.14.3Sign Off Documents The SoRT Sign Offs follows a two step process including a different Revision process. Sign off by Engineers A minimum of two people will be signing off each and every document. If a document is not signed off a user can select ‘not approved’ and can enter a comment. The author will then need to create a Revision of the document, which will need to be approved. The user cannot upload a new file on the rejected revision. The Document can be revised until it is approved by two competent Engineers. Once approved the document is “Issued for Use”. This is the last version of the REV A / B / C that was approved and can be handed over to client. Once Document is marked as “Issued for Use” the Document with all data is copied and REVO created. Sign Off by Client Once a REVO and following has been submitted, no new Revision can be created if an Engineer does not approve. The REV1 will need to be altered within that Revision until it is ready for Client Sign Off again. As soon as a new File is uploaded onto a REVO or higher the previous approvals are removed and new approvals have to be made. 5.14.4 Tag Sign Off A Tag is fully approved once all relevant calculations are compliant (See Calculations) All documents and calculations (that is essentially documents) have been approved by two competent people (Refer to Sign Off Documents) and an Engineer has marked the tag as “Engineering complete” An Approver can only mark a tag as “Engineering complete” if the Calculations are compliant, and documents have been signed off. If marked as ‘not Engineering complete’ the Approver can make a comment. Once marked as “not conform” the Engineer can make changes to the tag data. If changes are made the approver can check conformity again. If changes to a document are required, the Document has to go through the Revision Process. If marked as conform the tag data fields or that tag cannot be edited anymore. The Admin Master can however unmark the tag as complete, if necessary. 5.14.5 Calculation Sign Off The sign off will follow the same process and revisions schema as the document sign off. No exceptions have been specified. 5.14.6 Configuring Sign Offs The Master Admin and Lead Engineer can configure sign off. The following Sign offs can be configured. SoRT Classification SoRT Documents Tag Documents Project Documents Tag Conformity The user can simply add users from the project user list to the item to be signed off. Configuring sign offs should simply be seen as a procession of the project to the next stage and a means of making it easier for a user to track their projects. Users can filter for projects they are assigned to for Sign off in their project list. Users not assigned cannot sign off an element. Users assigned but without competencies cannot sign off an item. NOTE: whether a user is competent to sign off is defined in the project user details. That means even if a user is assigned to sign off a SORT, they might not be able to due to permissions. Users assigned to sign off Tag Documents Or Tag Conformity can only do so if they have the competencies. 5.15 HISTORY IMPORTANT - a user will need to see all historical information. That is all revisions, all comments on revisions, when it was approved, by whom, who created, when, when edited etc. The whole history of everything should be able to view. Certain fields within a form (history should be tracked in BE) 6 Inspection / Construction Stage Once a project is Engineering complete a next phase the Inspection and Construction Phase could be started. Systems or areas can be handed over to construction when all associated tags are engineering complete As part of this project the inspection and construction phase shall be covered only in its basics. 6.2 Project Users Additional users shall be added to the Project user list, inspection certificates and rights defined. It has not been specified which permissions apply and which certificates allow a user to perform a certain action at this stage. 6.3 Tag List Once a project is in Execution, the Tag List “Engineering’ Fields will be blocked for editing. Tag List Inspection field will be added that can be edited by a competent user. Please refer to Appendix C for additional Tag List fields. New tags can be added, however will need to go through the Sign Off process for Engineering. A Master Admin has the ability to unlock the Engineering fields and open for edit. This could potentially remove the “Mark as engineering complete” mark and force a new Engineering sign off. The process for what can be added and how it is tracked has not been defined. Non conform fields in inspection are highlighted. A comment can be made for non-conform text via a simple free text field. Note a tag could be conform even if the tag rules are not met. This could be the case if a classification report override is in place, however the SoRT had lower values defined. For that case the tag can signed off, however a comment or additional documents are required. Additional documents can be uploaded if a tag is not conform. E.g. a FFP or a Bulletin. The tag will need to be ‘unlocked’ for this. All documents would need to be signed off and the tag checked for Engineering conformity. No further specifications have been made. 6.4 Tag Rules Refer to Appendix E for Tag Rules relevant to inspection data. 6.5 Documents and Tags Upload of inspection documents and association to tags works in the same way as for the Engineering Phase. HAVD Document will be uploaded into the project (not tag related). 6.6 Sign Off All data entered Documents and additional tag data will need to be signed off by two competent people. The sign off process follows the same as Engineering Sign off process. No exceptions have been specified. HAVD Sign Off Two competent people and the client have to sign off on the HAVD. We suggest a form that will contain a list of checkboxes referencing the exported HAVD. All checkboxes need to be ticked. If not a comment can be made. If all ticked items are ticked by all required users the HAVD is approved. If not ticked and not approved, a comment can be made in the form. No process has been defined for HAVD Sign Off Revisions. The project status will change to HAVD classified, if approved. Configuring Sign Off Once the project is in status “Execution” additional sign offs can be configured for: Tag Documents Inspection Tags Inspection HAVD NOTE: whether a user is competent to sign off is defined in the project user details. That means even if a user is assigned to sign off a Tag document they might not be able to do so, due to their competency restrictions. Users assigned to sign off Tag Documents Or Tag Inspections can only do so if they have the competencies. 6.7 HAVD A HAVD Report can be created if all tags have been inspected and are conform. The Report will consist of a HAVD Document, all project, tag, SoRT documents and information on users and competencies. The export will bundle files together into Folders, i.e. all CADs in one Folder, all FFP in one folder etc. Export will be a Zip file with subfolders. No further information has been specified. Technical design and Admin Management Areas 7.2 General Technical Information Include information on: 7.3 Draft Entity Relationship Diagram | Draft Low-level Entity Relationship Diagram (Not showing all the fields in model or models) 7.4 Account Management N.B. management of the account view are only displayed to Total-Ex admin users. 7.4.1.1 List view 7.4.2 Accounts will be displayed in a list that will have search functionality based on the fields within the account model. 74.2.1 Create view An authenticated view with a standard account creation form consisting of a number of generic account fields and specific account workflow fields. Admins will have the ability to: Upload account records such as documentation relating to the account. Define account contact information Define an accounts specific abbreviations and codes 74.22 Edit view An authenticated view with the accounts current details displayed within form fields. The form fields and the account model will have appropriate validation to prevent inaccurate information from being saved. A save / update and cancel button will allow users to update or cancel the edit action. 7.4.3 Account Model 74.3.1 Accounts An account is an entity that has rights to use Total-Ex. An account will have one or more Admin users, that can then add additional users and create projects. Imperium needs to be able to grant access and licenses to users / accounts. No payment for now. Could do later License and tag number count (volume) - make up costs to pass on to users. N.B. The Account model doesn’t currently track any billing points (No Projects, Tags, Documents) Account instances will have authorship metadata recorded as per Appendix A. Account instances will have a deletion view as per Appendix G 7.5 User Management N.B. user views are only displayed to Total-Ex admin users, Account admins and Project Admin users. 751.1 Listview Users will be displayed in a list that will have search functionality based on the fields within the user models. 7.512 (Create view A view with a standard user creation form consisting of a number of generic user fields and specific user workflow fields. Admins will have the ability to: Upload user records such as certifications and documentation relating to the users competencies. Define the users role and groups and permissions based on the users competencies. Email the users nominated email, with instructions to activate their account. Define an email as username 7.51.3 Edit view An authenticated view with the users current details displayed within form fields. The form fields and the user model will have appropriate validation to prevent inaccurate information from being saved. A save / update and cancel button will allow users to update or cancel the edit action. 7.514 Delete view An authenticated view with the user current details displayed within a non-editable form. A delete / confirm and cancel button will allow users to delete or cancel the action. User Model User instances will have authorship metadata recorded as per Appendix A. User instances will have a deletion view as per Appendix G 7.5.2 User Roles - require breaking into groups N.B. Provided by the Imperium 7.5.3 User Required Competencies documents Users of the Total-Ex EEHA system are required to have specific competencies uploaded and approved before they can work on and approve a project. / . / Client Management N.B. client views are only displayed to Total-Ex admin users, account manager users 7.7.1 List view Clients will be displayed in a list that will have search functionality based on the fields within the client model. 7.7.2 Create view An authenticated view with a standard client creation form consisting of a number of generic client fields and specific client workflow fields. Admins will have the ability to: Upload client records such as documentation relating to the client. Define a client's contact information Define a client’s specific abbreviations and codes 7.7.3 Edit view An authenticated view with the client's current details displayed within form fields. The form fields and the client model will have appropriate validation to prevent inaccurate information from being saved. A save / update and cancel button will allow users to update or cancel the edit action. 7.7.4 Client Model Client instances will have authorship metadata recorded as per Appendix A. Client instances will have a deletion view as per Appendix G 7.7.5 Client management workflow 7.8 Project management N.B. Project Details, Users, SoRT, and Classification body are contained within a project. 7.8.1 Project SORT management A description of what exactly a “Schedule Of Release Table” is would be helpful here. 7.81.1 Listview A Project's SORT (Schedule Of Release Table) items will be displayed in a list table that will have search functionality based on the fields within the project model. 7.81.2 Create view An authenticated view with a standard SoRT item creation form consisting of a number of generic project SoRT fields. The user will have the ability to: Create an item within the schedule and define specific information per row / item. Define the Type of hazardous SoRT item. Create a Note / comment against an item. Upload records such as drawings and documentation relating to the item. Define a “Classification of areas based on the EEHA type e.g.. Oo Zone © Operating temperature o Grade © Flash Point © Explosive limit (upper & lower) © Ignition temperature o Gas Group o Temperature class © Density o Composition Define a location and human readable description Define a vertical and horizontal measurement Define a Tag No / Line No / Item No / Building No that can be used in by referenced by the Tag list 7.81.3 Edit view An authenticated view with the project SoRT details displayed within an editable form. The form fields and the project model will have appropriate validation to prevent inaccurate information from being saved. A save / update and cancel button will allow users to update or cancel the edit action. Project SoRT instances will have authorship metadata recorded as per Appendix A. Project SoRT instances must be non-destructively deleted (soft deleted) by default as per Appendix B Project SoRT instances have a deletion view as per Appendix G ome - on Weer (room ff sir of at Er (ami) 7.8.2 Project details management 7.82.1 List view Projects will be displayed in a Django ListView table that will have search functionality based on the fields within the project model. An Engineering Project can only be removed if it has no child data attached to it. 7822 FEditview An authenticated view with the project details displayed within an editable form. The form fields and the project model will have appropriate validation to prevent inaccurate information from being saved. A save / update and cancel button will allow users to update or cancel the edit action. Engineering Projects must be non-destructively deleted (soft deleted) by default as per Appendix B Engineering Project instances will have authorship metadata recorded as per Appendix A. Engineering Projects have a deletion view as per Appendix G 7.8.3 Project Classification management - allows users to upload the Classification report 7.831 List view A Project classification parts will be displayed in a list view that will have search functionality based on the fields within the project classification model. 7.832 (Create view An authenticated view with a standard project classification creation form consisting of a number on generic project classification fields and specific project workflow fields. The user will have the ability to: Download a Classification Template. Create and populate details about the new section. Define the name of the classification section that wish to populate Upload a document (TBD), that will be attached to the section. Approve and Activate the section and its attached contents. 7833 Edit view An authenticated view with the project classification details displayed within an editable form. The form fields and the project classification model will have appropriate validation to prevent inaccurate information from being saved. A save / update and cancel button will allow users to update or cancel the edit action. Project Classification instances will have authorship metadata recorded as per Appendix A. Project Classification instances have a deletion view as per Appendix G 7.8.4 Tag management N.B. This model structure has been identified from the “SITE - EEHA Scoping” document. 7.84.1 List view Tags within the project will be displayed in a Django ListView table that will have search functionality based on the fields within the project and tag models. 7.84.2 Create view An authenticated view that is accessible from within a project. The view will consist of a number of basic form fields. Certain fields within the workflow will prompt the user to attach media to the tag in the form of technical documents and other media formats through other modal views. The user will have the ability to: Upload a Tag list Add, edit and delete Tags Add additional documentation based on Total-Exs EEHA rules. Have a multi-user Sign-off process, based on user competency levels. Quarantine the completed and approved Tag list within the Project. 7.8.4.3 Colouring Specific columns and cells within the table will be highlighted based on calculations and the absence of required fields, documentation and sign-off from an administrative user. and model will have appropriate validation to prevent inaccurate information from being saved. A save / update and cancel button will allow users to update or cancel the edit action. 7.8.4.4 Approve Tag An authenticated view with the tags full information displayed within a non-editable form. The various sign-off reviewers sections and statuses will be visible and will show the current status of the full sign-off process. A sign-off button will allow users to sign-off the Tag. An export / confirm and cancel button will allow users to export or cancel the action Tag Model Tag instances will have authorship metadata recorded as per Appendix A. Tag instances have a deletion view as per Appendix G 7.9 Taxonomy model management N.B. management views are only displayed to administrators. These models will be displayed throughout the project but mainly in the tagging workflow. These models have been identified from the “SITE - EEHA Scoping” document. 7.91.1 Listview Taxonomy models will each will be displayed in a Django ListView table that will have search functionality based on the fields within the taxonomy model. The ListView will be broken into a paginated list. 7.91.2 Create view An authenticated view that is accessible from within a project. The view will consist of a number of basic form fields based on the models schema. 7.9.1.3 Edit view An authenticated view with the taxonomy models current details displayed in an editable form. The form fields and model will have appropriate validation to prevent inaccurate information from being saved. A save / update and cancel button will allow users to update or cancel the edit action. Taxonomy instances will have authorship metadata recorded as per Appendix A. Taxonomy instances have a deletion view as per Appendix G Taxonomy instances will have authorship metadata recorded as per Appendix A. Taxonomy instances will have a deletion view as per Appendix G 7.10 Document management 7.10.1.1 List view Documents will be displayed in a Django ListView table that will have search functionality based on the fields within the model. The ListView will be broken into a paginated list. 7.10.1.2 Create view An authenticated view that is accessible from within the user, client, asset, project and tag views. The view will consist of a number of basic form fields to capture document metadata and a fileupload field that will allow users and users to attach media to the section in the form of technical documents and other media formats. 7.10.1.3 Edit view An authenticated view with the documents current details displayed in an editable form. The form fields and model will have appropriate validation to prevent inaccurate information from being saved. A file input field will allow users and users to re-upload documents. A save / update and cancel button will allow users to update or cancel the edit action Document instances will have authorship metadata recorded as per Appendix A. Document instances will have a deletion view as per Appendix G 7.11 Revision management N.B. management views are only displayed to administrators. 7.11.1.1 List view An authenticated view that is available within the management view and only accessible to Total-Ex admins and Account and Project Admins. Revisions will be displayed per model and will be displayed in a standard list table that will contain the user and amend that occurred and the revision number. The list view will have search functionality based on the fields within the model that is being inspected.. 7.11.1.2 Export list view An authenticated view with the revision information displayed within a non-editable form. An export / confirm and cancel button will allow Admins to export or cancel the action. 8 Appendix A: Authorship For models that require authorship tracking, the following information will be recorded: 9 Appendix B: Soft deletion For models which have been noted as requiring soft deletion, the following metadata will be recorded for each deletion event: Which user deleted the record When the deletion event occurred The state of the record immediately before it was deleted (i.e. the record data itself will not be deleted) 10 Appendix C: Tag List NOTE that validation defined hold true if no classification override is in place. If a classification report override has been defined tag data is validated against the override. 11 Appendix D: Calculations Heat dissipation calcs The method to determine this is as follows: From the certificate for a given required HA area T class — determine what the allowable heat dissipation is — this will be in Watts. (PTolerable) Determine the terminal sizes and what their resistance value is = Zt1, Zt2, Zt....x Determine cable sizes going to the terminals are. Cable length (in and out all inclusive) shall be considered as the 3-dimensional diagonal of the JB as in Sqrt of (Width”2 + Length”2 + Depth”2) Determine each cables impedance value is per circuit = Cz1, Cz2, Cz.....x Determine each circuits current is = Icl, Ic2, Ic.....x Heat dissipation per circuit shall be P1=|22*Ztotal © Ic1 / 2 * (Cz1+Zt1) Total heat dissipation shall be: Ptotal = P1 + P2 + P....x A pass is when PTolerable > Ptotal 1S “i” calculation See IS-Loop Calculator Template 6 Notes: (i) Instrument data Li, Ci and Pi values will change almost every calculator unless it is repetitive. (ii) Cable data may remain constant with the exception of length. That said it is advisable to allow direct entry of cable values (iii) Barrier data Li, Ci and Pi values will change almost every calculator unless it is repetitive. (iv) There may need to be up to two JBs terminations in the field prior to the device 12 Appendix E - Tag Rules 12.2.1 Tag Rules Rules defined below will be applied to specific fields within the tag workflow. Inspection Relevant Note: Tag and SoRT list are per default to be checked for inspection relevant data. If a classification report override has been created for a specific area, this will be applied. 1. "Equip Gas Group" and ‘Area Gas Group’ Relation a. Only IIA equipment can be used b. IB equipment can be used in IIA and IIB areas ¢. IC equipment can be used in I|A and IIB and |IC areas Check whether Equip Gas Group Field and Area Gas Group field in tag list are filled in accordingly. 2. Equip TEMP Class" field in EEHA. If cell contains e.g. "T4", "Area Class Temp Class" cell, needs to have T1,T2, T3, T4. Classification of maximum surface temperatures for Group Il electrical equipment a. T6 equipment may be used in T6 / T5 / T4 / T3 / T2 / T1 areas b. T5 equipment may be used in T5 / T4 / T3 / T2 / T1 areas c. T4 equipment may be used in T4 / T3 / T2 / T1 areas Engineering Relevant 3. Gasses and vapours - Relationship between EPLs and types of protection and applicable standards a. if "Zone 0" equipment MUST be "ia" or "ma" or "s" else FAIL. The rule shall be extended per the below table for zones 1 / 2 / 20 / 21 / 22 i. Exdesign Technique field" - check on values and check whether the correct Zone in "Zone" field has been entered. Table been provided 4. Simple Apparatus Exception a. Adevice can be installed as part of an Ex "i" loop and not be certified if it is deemed to be a "Simple Apparatus” - if "Ex "I" and not certified it must have an SAA. is CAD can be marked as not needed, then the SAA fields needs to be required. If SAA not applicable either FFP will need to be required. 1. Summary: a. if Ex Design Technique is Ex"i" and CAD is n / A, SAA must be provided b. If Ex Design Technique is Ex"i” and CAD is n / A and SAA is n / A, an FFP must be provided 5. Exdesign Technique Ex “e” requires Heat dissipation calculation a. To clarify which method / fields 6. Exdesign Technique Ex “i” requires IS Entity calculator AND there must be IS barrier details entered. 6 a Rule name - TBD a. Rule 7 also applies to the IS Barrier for the equipment identified in Rule 6. 7. "Certificate of Conformity number" must contain or starts with "IECEX" OR "ANZEx". If cell contains "NO", the "Conformity Assessment Document Number" needs to be entered into TAG List. E.g. tag is not engineering complete if no value in Certificate of Conformity and no value in CADno. entered. 8. Exdesign Technique Ex “p” and “v” requires method statement unless conformity logic in CoC. a. Manual check whether COC has Conformity Logic included. If it does not user needs to upload a Method Statement. b. If Ex "p" of "Vv" a pressurisation / ventilation method statement is required, this is complete with a test procedure. Method Document must be uploaded 12.2.2 Rule tables 14 Appendix G - Delete Views An authenticated view with the sections current details displayed within a non-editable form. A delete / confirm and cancel button will allow users to delete the loaded information. A cancel button will also allow users to cancel the action and return them to the sections view.

Claims

Claims 1. A hazardous area information development method comprising: designing a plant comprising a hazardous area; allocating an identification to one or more components of the hazardous area; for each component, recording the identification against information related to the respective component; building the plant, tagging each component with an indicator of the identification of the component; whereby the indicator of a selected component of the plant is able to be read so as to determine the identification of the selected component; and so that the recorded information about the component can be retrieved according to the determined identification of the selected component.

2. A method according to claim 1, further comprising retrieving the recorded information about the component according to a determined identification of one of the components.

3. A method according to claim 1 or 2, further comprising appending further information in the stored information about the component over time and scanning the tag to access the stored information about the component at a subsequent time.

4. A hazardous area information retrieval method comprising: in the engineering / design phase of designing of a plant comprising a hazardous area, allocating an identification to one or more components of the hazardous area; for each component, recording the identification against information related to the respective component; in the build phase of construction of the plant, tagging each component with an indicator of the identification of the component; in the operation phase of the plant, reading the indicator of a selected component of the plant so as to determine the identification of the selected component; and retrieving the recorded information about the component according to the determined identification of the selected component.

5. A method according to any one of the preceding claims, wherein each component has a component type, and the recorded information for each component comprises the component type and information specifically related to the respective component.

6. A method according to claim 5, wherein the recorded information for each component comprises information related to components of the component type. 7 A method according to any one of the preceding claims, wherein the components are organised in a hierarchy of systems, sub-systems and individual components thereof and information about or representing the hierarchy is recorded and is usable to retrieve information about other components so related to a selected component.

8. A method according to any one of the preceding claims, wherein the indicia also comprises the component type.

9. A method according to any one of the preceding claims, wherein the step of retrieving the hazard information also comprises retrieving information about the component type.

10. A method according to any one of the preceding claims, wherein the method further comprises recording a change made to the component against the component identification.

11. A method according to any one of the preceding claims, wherein in the build phase the method further comprises recording with the information about the component an item / part identifier of the installed type of component.

12. A method according to any one of the preceding claims, wherein the item identifier comprises a serial number.

13. A method according to any one of the preceding claims, wherein in the operation phase when one of the components is replaced then the method further comprises recording the changed item / part identifier against the component identifier in the plant.

14. A method according to any one of the preceding claims, wherein in the operation phase when one of the components is changed then the method further comprises recording the changed component identification and information relating to the component.

15. A method according to any one of the preceding claims, wherein the recorded information comprises one or more of the following: hazardous area classification; drawings and / or models of the hazardous area; sources of release of hazardous substances (eg sources of release of flammable fluid); intrinsic safety (IS) calculations; conformity to standard(s) requirements assessment document; fitness for purpose report; models and data for import from or export to a 3" party software and / or drafting package to identify a Hazardous Zone; 3D models of the plant or components of the plant; 2D models of the plant or components of the plant; computer flow dynamic model for each component.

16. A method according to any one of the preceding claims, wherein after the design phase and prior to the build phase, Inspection and Test Report (ITR) data are compiled from the recorded information for each component to be installed during the build and the Inspection and Test Records are completed upon completion of the build phase with information derived from the build phase, such as when additional information is developed to ensure compliance.

17. A method according to claim 16, wherein each ITR is recorded in association with the component identification.

18. A method according to any one of the preceding claims, wherein the information available to an inspector during the operations phase is restricted.

19. A method according to any one of the preceding claims, wherein the ITR is presented in the form of a document for completion by an inspector, the document constructed according to information recorded against a scanned tag and constructed according the associated component type with current information and access to historic information.

20. A method according to claim 19, wherein the completed form comprises as attachments information obtained from the retrieved record associated with the component identification.

21. A method according to claim 20, wherein this comprises at least one or more of the following: a previous certificate of conformity; conformity assessment documents; intrinsically safe calculations and information; fitness for purpose documents; Simple Apparatus Assessments; calculations (eg. heat calculations and IS calculations).

22. A method according to claim 21, wherein the information in claim 21 is locked from modification unless certain criteria are met.

23. A method according to any one of the preceding claims, wherein the indicator is a near field device (such as an RFID tag), a bar code, a QR code, a readable label with an identifier printed on it, or other suitable identification means.

24. A hazardous area information retrieval system comprising: a processor configured to allocate an identification to one or more components of the hazardous area in the engineering / design phase of designing of a plant comprising a hazardous area; a data storage for recording information related to components and for recording the identification against the information for each component; a tag applied to each component in the build phase of construction of the plant, the tag comprising an indicator of the identification of the component; a tag reader for reading the indicator of a selected component of the plant so as to determine the identification of the selected component in the operation phase of the plant; and the processor further configured to retrieve the recorded information about the selected component according to the determined identification of the component.

25. A computer program for a hazardous area information retrieval stored on computer readable media comprising instructions for controlling a computer to: allocate an identification to one or more components of the hazardous area in the engineering / design phase of designing of a plant comprising a hazardous area; record information related to each of the components; record the identification against the information for each component; record an identification of a tag applied to each component in the build phase of construction of the plant; receive the indicator of a selected component of the plant read from the tag so as to determine the identification of the selected component; and retrieve the recorded information about the component according to the determined identification of the selected component.

Images