GoTechnology Hub2 User Guide

User Manual:

Open the PDF directly: View PDF .
Page Count: 40

Download
Open PDF In Browser	View PDF

1. About
1.1.1. Introduction
This user guide describes an introduction or reference guide for some of the more complex features of
GoTechnology hub2; Wood’s next generation completions and commissioning management solution.
The document contains screen shots and information that were relevant at the time of release. As
GoTechnology hub2 is a continuously developed product the actual appearance or function may differ from
what is depicted.
In addition, some sections or operations shown may not be accessible due to permissions issues.
For the latest information on GoTechnology please visit http://qedi-gotechnology.github.io or contact
commissioning.info@woodplc.com

1.1.2. Intended Audience
It’s expected that readers will have completed the required training courses, and understand the fundamental
concepts and basic operations, before reading this document.
This guide is intended for authorised users only and should not be distributed without the express consent
of Wood.

1.1.3. hub2
First released in October 2017, hub2 is the latest generation of Wood’s GoTechnology family of online, webaccessible completions and commissioning management solutions.
Intended as a replacement for all previous products within the range, hub2 delivers the facilities to track,
record and report on details of equipment, certification, handovers, procedures, preservation routines and
Job Card information, amongst others.
Access
Details of how to access GoTechnology hub2 will be provided separately. Please note: As hub2 is a primarily
online solution, an internet connection and a modern, HTML5 compliant web browser are required.

1.1.4. Glossary of Terms / Listing of Information
At the end of this document is an abbreviated list of the information stored within hub2, where it can be
viewed from, and which Level within the information hierarchy (described in 3 Levels below) it resides.
Important Note: This is not a complete listing and is intended for basic reference purposes to the most
commonly used areas of GoTechnology hub2. Client, industry or process specific information types will be
excluded for this reason.
GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

2. UI
Let’s take a look at the User Interface (or UI) for hub2. This is the “look and feel” of the application: How
information is displayed onscreen and how you interact with it.

Depending on which version of hub2, your preferences, permissions and configuration, and the device your
viewing on, some elements may appear differently, or not at all.
If we apply some highlighting to some different elements on this screen we can cover a lot of the basic
concepts within hub2, which follow all the way through the application.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Colour

◼

Location

Top of screen
(menu bar)

Element

Description
The top menu buttons are the key to
navigating hub2. Clicking one of
these buttons will open a drop-down
menu with links to specific pages.
This includes the button at the top
right, which displays your name (or
the name of whoever is currently
logged in) and provides links to User
preferences and options.
The

◼

navigation

“breadcrumbs”

show which Level A / Level B /
Top Right

Level C / Level D you’re currently
logged in to. Click any of these
elements will take you back to the
Level select screen.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

The final breadcrumb element

◼

represents the Level E. Clicking
Top Right

this will provide a drop-down of
other Level E’s within this Level D,
allowing you to quickly switch
between them.
A drop-down menu that provides
the five most recent searches

◼

you’ve run, allowing you to re-run
Search Header

them easily.
Lists any “Saved Searches” you
have created via the “Save Search”
button.
Buttons within hub2 have many
purposes but are mainly used to

◼

Various locations,
throughout hub2

trigger an action, whether it’s to
start a search or import, add or
delete an item, or, in the case of
the button shown to the left, clear
all the values from a form.
The quick search bar can be used

◼

to enter multiple search fields in
Near the top of

one place.

the search form

In addition, the drop-down arrow,
when clicked, provides a list of
field definitions.
Input fields can be used to enter
search terms or add data.

◼
Various locations,
throughout hub2

This can be either typed directly,
or in the case of dates, selected
from a date picker.
For

“lookup”

fields,

the

magnifying glass button on the
right can be clicked to open a
popup containing all the possible
values that can be selected.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Alternatively, a value can be typed
in directly as normal.
Fields which are “Required” have
the word Required shown when
they are empty.
When a field is Required it means
that it won’t be possible to add a
new record if those fields are
blank

contain

invalid

information (and hub2 will tell you
if the information is invalid).

3. Levels
Within hub2 project information is stored in five connected levels. This might seem like a more complex
approach than you’re used to before, but once we’ve explained it, you’ll understand how it’s easy to use, and
will save time and improve consistency of data. Within the structure, inheritance is used: Information defined
in the first level flows throw to the second, third, fourth and fifth levels, information in the second flows throws
to the third, fourth and fifth level, and so on.
Within this document, we will refer to these levels as Level A, Level B, Level C, Level D and Level E, however
they can be renamed by yourself or your hub2 administrator to use names that are much more relevant to
your project or industry.
Here’s an example of how an instance of hub2 might be laid out. Don’t worry too much about the details at
this stage, we’ll go into those later!

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

As you can see, in the above picture we have a fictional company named “Astro Works”, and a data structure
that’s been designed in hub2 to best support their operations. This structure will allow the Astro Works teams
to share the information they need, while making it clear who is working on what, and ensuring that any
information is only available to the appropriate persons.
So how do we build up a structure like that, and what do these levels really represent? We’ll get into that in a
second, but before we do, an important point.

An Important Point about Levels
You (or your hub2 administrator) can change your Level configuration
whenever you need to, so don’t worry about having to get it right first time.

If you’d like some advice on Level configuration, just get in touch. We’re
here to help!

When it comes time to build up our data within hub2, we start at the “top” of the data hierarchy (Level A) and
work our way down from there.

3.1.1. Level A
As we know, Level A represents the “Company”, “Corporate” or “Global” level. It contains configuration options
that will be utilised in every part of the world, in every industry, on every project and work scope the
company does… Or at least that’s the idea! Of course, in reality this may not be practical, but we’ll discuss that
later.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

For now, let’s assume that there’s just one item in Level A representing the whole company. In our example
case, that is Astro Works, our fictional space exploration organisation.

There’s no data stored at this level, but there are some options:
•

Aliases

Aliases allow us to “rename” certain items on screen. As we’ve mentioned these can include the Levels
themselves, as well as other items such as Certification Grouping. When we set an Alias for any field then the
default name is replaced by the alias we’ve chosen.

In the above screenshot, the orange highlight shows that there are no Alias at present, just the “Add Alias”
button. The purple highlight shows that the default “Level A” to “Level E” are shown.
Let’s rename those to some more friendly values.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Once we save we can see the menu has updated too.

3.1.2. Level B
Level B represents the first sub-division of the structure and is the first place we can actually store data. It’s
usually used to represent a region, division or industry sector.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Information at Level B
The kind of information we store at this Level is very high level
Remember, any information set here will be used by the associated levels below:

In the above picture we can see our two Level B’s (which we’re calling “Regions”) Astro Works Texas and
Astro Works Florida, containing different information (which is shown by having one in purple and one in
orange).
GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

The solid colour indicates where the information is set, with the outlining showing where the information is
used or referenced from.
As you would expect from our previous explanations, Levels below, reference the information defined in those
above (by now we’re hoping this is becoming painfully obvious, and even repetitive, to you.

3.1.3. Level C
Level C is usually used to represent a physical construction or geographic area in which multiple projects
(which themselves have multiple scopes of work) are being (or will be) executed.
As such it contains a large amount of data, as well as a few key configuration options:
•
•
•

Preservation Progress Method
Preservation Window Before
Preservation Window After

These are described in more detail, and in context, in 8 Preservation.
Let’s go back to our diagram and take a look at Level C in more detail

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Just to repeat our previous point once more, the information set at Level C, will be utilised by the levels below:

3.1.4. Level D
Level D is the “Project” level, and represents a grouping of work scopes (which are recorded at Level E). As
such, there’s not too much data stored here and, aside from the logos which appear on reports and
certification, only one setting:
•

Punch List Item Auto Number – Set whether Punch List numbers are generated automatically, and any
conventions/formats for that number.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

As we know, the information at a higher Level is referenced by those beneath it. This time we’ll show the
structure without highlighting. Can you imagine which Level E’s inherit from where?

We’re sure you figured it out – it’s just a case of tracing the lines.

3.1.5. Level E
Level E represents the scope of work – it’s where sign-offs are stored and progress is recorded.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Level E is the lowest level, so any of our Level E’s (or “Scopes” as we’ve aliased them) won’t affect anything
other than themselves.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

4. Permissions

Permissions within hub2 have a high level of flexibility: Authorisation can be fine-tuned for almost every table,
to specify if a User can Add, Update, Delete or even see it at all. There are also additional special permissions
for certain tables, such as the ability to sign-off Tag ITRs or Tag PWLs.

To make all these Permissions easier to manage, we have a couple of tools at our disposal. Firstly, permissions
can be grouped together as a “Role”. Secondly, we can choose which Level we “Assign” a Role or Permission
too – this is because the abilities of a Role are limited/linked to the Level it’s assigned to and it’s “children”
(for example, Tags are managed at Level C. If we assign a role for creating tags, but only on a Level D or a
Level E, then the User won’t be able to do anything.)
We’ll talk more about that later though. Let’s start off by looking at Roles.
The standard roles within hub2 are as follows (correct at time of writing):
Role

Permissions Included

Tag Full Permissions

Tags, Test Packs, Lines, Spools, Cables and Mech Joints:
•
•
•
•
•

Tag ITR Sign Off

Tag ITR:
•

Tag ITR Full Permission

Sign Off

Tag ITR:
•

GoTechnology hub2 User Guide

Create (Add)
Read (View)
Update (Edit)
Delete
Import

Create (Add)

For Authorised Users Ony. Do not distribute.

•
•
•
•
•
•

Punch List Raise

Punch List, Punch List Item:
•

Punch List Sign Off

Sign Off

Handovers:
•
•
•
•
•
•

Level Administrator

Sign Off

Procedure, Procedure Section, Procedure Step and MOC:
•

Handover Full Permission

Sign Off

Handovers, Punch List Items, Tag ITR, and Tag PWL:
•

Asset User Sign Off

Sign Off

MOC:
•

Scope User Sign Off

Create (Add)

Punch List Item:
•

MOC Sign Off

Read (View)
Update (Edit)
Delete
Import
Review (Access the “Equipment Type to ITR Review” page)
Full Tag ITR Digital Document permissions (fill in Tag ITRs onscreen, or
via “Smart” PDFs)

Create (Add)
Read (View)
Update (Edit)
Delete
Import
Sign Off

Levels A, B, C, D and E:
•
•
•
•

Create (Add)
Read (View)
Update (Edit)
Delete

Note: This allows the creation of the Levels themselves. So new “Regions”,
“Assets”, “Projects”, etc can be created by this user. However, on its own it
does not give them permission to perform any tasks (e.g. create Tags, signoff Tag ITRs, etc) within any levels.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Full Write Access

This is the opposite of the Level Administrator in that it grants full
permissions to do everything (Create, Read, Update, Delete, Import, Sign
Off, Review) except the actual creation of Levels themselves.

Importer

Import Access for all tables expect Level A to E

Scope Importer

Tag ITR, Punch Lists, Punch List Items, Tag PWL, Procedure, Procedure Step,
Procedure Section, Primary Handovers, Secondary Handovers and
Handovers:
•

Template Admin

Import

Handover Types, ITR, MOC Type and PWL:
•

Upload (add/replace DOTX templates)

Base Access

Read Access to all tables

Asset User Sign Off

Procedure, Procedure Section, Procedure Step and MOC:

Attachment Upload

• Sign Off
Attachments:
• Create (Add)
• Read (View)
• Update (Edit)

As you can see, some of the roles overlap. That’s ok – it won’t cause any problem if someone has the “same”
permission twice.
In general, our advice is to go for the fewest amount of permissions possible, as it makes it much clearer who
can do what.

Now we have our Roles, but how do we choose which “Project” they apply to? And how do we make the
whole process as flexible as possible, while still making it quick and easy to change?
The answer is through how we assign these roles, and in hub2 any role can be assigned at any level.
Let’s look at our Level Diagram again:

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

So, we can assign any of the roles listed in the table above, to any of the Levels in that diagram. We could
assign it to any Level A, any Level B, any Level C, any Level D…. Well, let’s start off with something easy… Let’s
assign permissions so that a User can create Punch List Items in any of the “Scopes” (Level E’s) in the Houston
Research Facility (Level C).

4.2.1. A simple example of assigning a role to multiple scopes.
First, we need to know what Role to choose. If we look back at the table we can see that “Punch List Raise”
does exactly what we need, and nothing more. Sounds perfect!
Now, where to assign it? Well, we could assign it to each Level E itself:
•
•
•
•
•

Fuel Pump
Booster Housing
Enclosure (Hot Gas)
Coolant
Create Initial Plan

But there’s an easier way! You might be able to guess as to what it is (keeping in mind what we know about
how Levels work, and that we can assign permissions at any Level), but if not, here it is:

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

By assigning the Permission to “Houston Research Facility” then the permission applies to all levels beneath.
This also means that if a new Level E is added, then the User with this role will automatically have permission
to Create Punch Lists and Punch List Items there too.
If, on the other hand, we only wanted to assign to specific Level E’s (let’s say all of those in “Houston Research
Facility” except “Coolant”)

As we can see, there’s no one “right” way to do things. We can accomplish the same outcome in several ways,
mixing and matching Roles and Levels to get the right result.
Let’s look at another, more complex example.

4.2.2. Achieving the same result in different ways
Depending on what Role we choose and what Level we assign it, we can achieve the same result in different
ways.
GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Understanding this can help us grasp how the Permissions system works.
Let’s imagine an example where we want to give a User permission to import to all Level E’s within “Houston
Research Facility”, but only the items stored at Level E (Tag ITR, Punch Lists, Punch List Items, Tag PWL,
Procedure, Procedure Step, Procedure Section, Primary Handovers, Secondary Handovers and Handovers).
Well, let’s look back at what Roles are available for Importing…
Role

Permissions Included

Importer

Import permissions for all tables expect Level A to E

Scope Importer

Tag ITR, Punch Lists, Punch List Items, Tag PWL, Procedure, Procedure Step,
Procedure Section, Primary Handovers, Secondary Handovers and
Handovers:
•

Import

The first option (Importer) looks like it might be overkill for what we need, as we only want to import the
tables which are at Level E. However, the second option (Scope Importer) matches perfectly. If we assign that
to “Houston Research Facility”, we get exactly the result we want.

Perfect!
But could we achieve the same result with the other Role as well? As it happens we can:

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

How does this work? Well, even though the “Importer” role specified access to import all tables, what it really
should say is “Provides import permission to tables belonging to the Level it is assigned to and to the tables
belonging to any child levels, except for the tables representing the Levels themselves.” But that’s a bit wordy!
So, by assigning a powerful permission at a low level, we limit its power. As with data, permissions flow
downwards. By assigning the ability to use any import, but allocating it to a Level E, what we actually get is
that any Import within that Level E can be used. So, assigning it to those four Level E’s gives us what we want
in a different way.

5. Beyond Levels: The Extended Logical Structure of hub2
Now we know all about Levels, what’s stored there and how we can set up the right permissions, but what
happens when we go deeper? How is information within a Level E structured to allow us to assign, progress
and track Completions and Commissioning execution? The answer can be seen by delving into the “Scope”
level and looking at what we call the “Extended Logical Structure”:

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

While this might seem complicated, the main principles are quite simple:
•
•
•

We’re already familiar with Level A to E and what they represent.
Work Packs and Activities are the next subdivision of data. Work Packs represent the physical documentation
and Activities represent the effort involved in completing the work.
When a Project is planned a Work Breakdown Structure is created, decomposing the overall Project (Level D
in hub2 and Level 1 in most planning approaches) into two further levels: Scopes of Work (Level E in hub2,
Level 2 in planning) and Work Pack or Activity (in hub2 we track both)

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

•
•
•

Beneath this, comes Job Cards which represent both physical documentation and a planning activity.
After this comes Tag ITRs (documentation) and Operations (planning activity)
Finally we go a level beyond what a project plan would reasonably expect to capture, to the actual Task level
of the Tag ITRs.

As you can see, hub2 captures quite a depth of information, allowing the status of entire facilities to be
accurate down to the individual checkboxes being completed on a Tag ITR.
You can probably also see why we used A to E as the “behind the scenes” names of our Levels (and remember,
you or your hub2 administrator can adjust the terminology to be relevant and easy to understand for your
company) instead of 1 to 5.

6. Populating Data
Once permissions and levels are in place it’s time to start adding data. Depending on what level (and
permissions) you have access to, as well as the way hub2 is set up for your company or project, the actual
specifics of what you can and can’t change may vary, but we can cover the basic concepts involved.

Reference Tables are the building blocks of hub2. Normally the information contained within the Reference
Tables is simple, perhaps just a Name and a Description, but they exist to provide a library that the more
complex elements can draw from, increasing consistency of data and reducing rework.
To make it easy to find the Reference Tables, they have their own tab on the top menu, and are listed second
from the left, just after the Imports:

If you have a look, you’ll see there’s quite a lot of them, however we don’t need to populate them all at the
same time (or ever if they’re not required!) only the ones that we know, or that we need to move forward and
set up the more complex entities.
As an example, let’s look at what Reference Tables we need to add our first Tag.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Tags have a lot of fields, but only a few of them are
Required.
For Tags the standard required fields (as of the time of
writing – things do change!) are:
•
•
•
•
•

Name
Discipline
Description
Equipment Type
Subsystem

And of those, Name and Description are not Reference Tables. Remember, as we described in the UI chapter,
we can tell which fields are Required, and which are Reference Tables just by looking at the fields themselves:

Required fields have the word “Required” inside the text box when they are empty:

Reference Tables have a blue magnifying glass button at the right-hand side:

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Clicking on this button will open a pop-up window, from which you can select the information you want:

If the pop-up window is blank, that means there is no data in the reference table:

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Now we know that, as there are no records available, we need to go into that Reference Table and add some
values in and we’re ready to go.

7. Handovers
Handover Certificates, usually referred to simply as ‘Handovers’ are used to guarantee Technical Integrity
when responsibility is being transferred between Authorities.
Exactly what is being handed over, and when, varies between company, project and geographic location.
Because of this, GoTechnology® applications have a flexible approach, with a variety of configurations which
can be used on a “per-project” basis (Level D within hub2) allowing each to have its own Handover
configuration.
The key components in each Handover are:
1. Name
2. Grouping
3. Gating
While the name is self-explanatory, the Grouping and Gating require further explanation.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

7.1.1. Grouping
The Handover Grouping controls the “what” of the Handover, as in “What is it that I am handing over?”
Perhaps the most commonly used Handover Groupings are System and Subsystem (e.g. when a Subsystem
Handover is completed it represents a statement that responsibility for that Subsystem can be transferred
onwards) but there are other categories too. The following groupings are available in hub2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Certification Grouping
System
Subsystem
Primary Handover
Secondary Handover
System / Discipline
Subsystem / Discipline
Area
Module
Level E

7.1.2. Gating
The Handover Gating determines the “which” (the ‘scope’) and “when” (the ‘ordering’) of the Handover within
the overall project, serving to answer the questions “Which certificates/ITRs are covered by this Handover and
when in the complete Handover process should this particular Handover occur?”
Both questions are answered with a single field: The Handover Gate Number.
This field acts as both a link between the Handover and the ITR Classes as well as means of ordering the
Handover within the project.
Example: How Gating affects ordering.
As an example of how this works, consider a scenario where there are three Handovers (please note these are
intended as examples only):
Handover

Gating

HOC

MCDAC

PCDAC

The Handovers are listed above alphabetically; however, in terms of the order within the Process, the MCDAC
comes first, followed by the PCDAC and finally the HOC.
We can expand this further with an additional Handover:
Handover

GoTechnology hub2 User Guide

Gating

For Authorised Users Ony. Do not distribute.

CCC

HOC

MCDAC

PCDAC

Now we can see that both the CCC and the MCDAC are to be completed first, followed by the PCDAC and
HOC.
Example: How Gating affects scoping.
If we retain our previous set of four Handovers and introduce a table listing our ITRs and ITR Classes we can
see how Gating affects scoping too.
ITR

Gating

Class
COM

Now we know that our CCC and MCDAC cover all ITRs in the MC ITR Class, our PCDAC covers all in the PC
class and our CCC in the COM class.

7.1.3. Walk Downs
Another key element in the handover process involves the physical inspection of the scope of the Handover
(be it a System, Subsystem, Area or something else) by the process stakeholders. This process is known as a
Walk Down.
There may be multiple Walk Downs held but all have the same general purpose: To identify any unrecorded
defects and to verify that defects which have previously been identified have been actioned appropriately.

8. Preservation
Preservation involves tasks related to ensuring unused equipment is kept in working condition. These tasks
are often repeated on a regular schedule, to ensure the equipment is properly maintained and ready to use
when required.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

8.1.1. Preservation Work List (PWL)
Within hub2 ‘Preservation Work Lists’ (PWLs) are used to record the completion of preservation tasks, and
can be assigned to Tags, in a similar fashion to ITRs. The difference is that PWLs are part of a regular schedule
of maintenance on unused equipment, while ITRs are used to sign-off that installed equipment is safe and
has been properly tested as part of the Handover process (in which the goal is to start, or restart, the facility).

8.1.2. Tag Preservation Work List (Tag PWL)
Just as a Tag ITR represents an actual assignment of an ITR to a Tag so does a Tag PWL represent a PWL to a
Tag. To explain this further; our PWL table will contain an entry for each type of Work List available for use.
So, if there are ten different Work List types (perhaps named ‘PRES-A’, ‘PRES-B’,’PRES-C’ and so on) then there
will be ten entries in the PWL table.
However, any one of these PWLs may be assigned multiple times to many different tags. This is where the
Tag PWL entity comes into play; storing the details of each Work List the user creates and assigns.

8.1.3. Frequency
The Frequency of a Tag PWL describes how regularly the applicable preservation work should be performed.
If a Tag PWL has a Frequency of seven days, then it should be performed once every week.
If it has a Frequency of 365 days it should be performed once, and then is not due for another 365 days, either
from the Due Date (so the schedule remains consistent) or from the Sign-Off Date (so the schedule adjusts
based on when the Tag PWL was actually signed off), depending on the configuration of hub2.

8.1.4. Due Date and Sign-Off Date
The Due Date is when the Tag PWL is expected to be completed by, while the Sign-Off Date is when the Tag
PWL was actually signed off. It is possible in hub2 to apply restrictions to when Sign-Off can be accomplished,
via the Level C Preservation Window Before and Preservation Window After settings.

8.1.5. Preservation Window
The Preservation Window (via the Preservation Window Before and Preservation Window After fields on Level
C) allows restrictions to be placed on when a Tag PWL can be signed-off, specifically in relation to the Due
Date.
The settings allow the Preservation Window to be restrict how many days before and how many days after
the Due Date is acceptable. These values can be different. If either (or both) value is left blank, then no
restriction applies.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Examples
8.1.5.1.a.

Due Date: 14 February 2017
Due Date

Preservation

Acceptable Sign-Off Values

Window
Before
14

After

February

Any

2017
14

February

Any date before 17 February 2017.

February 2

12 February 2017 to 16 February 2017.

February 5

9 February 2017 to 16 February 2017.

2017
14
2017
14
2017
8.1.5.1.b.

Due Date: 20 March 2049
Due Date

Preservation

Acceptable Sign-Off Values

Window
Before

After

20 March 2049

Any

20 March 2049

Any date before 19 March 2049.

20 March 2049

17 March 2049 to 24 March 2049

20 March 2049

17 February 2049 to 5 April 2049

8.1.6. Preservation Progress Method
Preservation Progress Method is a Level C setting which will be used to determine the next Due Date when
advancing Preservation which is being signed off. When any Tag PWL item which has a populated Frequency,
field is signed off a new Tag PWL record will be created and its Due Date will be set based on the Preservation
Progress Method as detailed in the following table:

Preservation

Due Date

Sign Off Date

Progress Method

Advanced

Due

Date

(Frequency of 5 Days)

Due Date

15/01/2016

18/01/2016

20/01/2016

Sign Off Date

15/01/2016

18/01/2016

23/01/2016

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

9. Imports & Exports

It’s recommended that Imports are kept at 20,000 rows or less per file for performance reasons.

The recommended order to perform Imports is listed below:

9.2.1. List
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
21)
22)
23)
24)
25)
26)
27)
28)

Primary Handover (if applicable)
Secondary Handover (if applicable)
Location
Module
Area
Priority
System Group
System
Subsystem
Loop
Activity
Authorised Person
Unit of Measure
Test Pack Type
Discipline
DrawingType
Drawings
Certification Grouping
ITR Class
ITR
Q Pack (if applicable)
Equipment Status
Equipment Type
Equipment Type to ITR
Parent Tag
Tag ITR Completion Status
Tagged Item
Tag

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

29)
30)
31)
32)
33)
34)
35)
36)
37)
38)
39)
40)
41)
42)
43)
44)
45)
46)
47)
48)
49)
50)
51)
52)
53)
54)
55)
56)
57)
58)
59)
60)
61)
62)

Tag ITR
Tag Q-Pack
Tag Subsystem
Test Pack
Work Pack
Procedure
Procedure System
Procedure Section
Procedure Skeleton
Procedure Skeleton Section
Procedure Skeleton Step
Procedure Step
Punch List Item Category
Punch List
Punch List Item
Job Card
Handovers (multiple)
Preservation Completion Status
PWL
Equipment Type to PWL
Tag PWL
Line
Spool
Mechanical Joint
Cable
MOC Type
MOC
MOC Discipline
MOC Primary Handover
MOC Secondary Handover
MOC System
MOC Subsystem
MOC Tag
MOC Work Pack

10.

Glossary / Listing

Name

Activity

Description

Menu
Location

Activity within hub2 represents Level 3 in the recommended Work

Reference

Breakdown Structure and as such exists as the “parent” of Job Cards

Table

Level
E

and as a “child” of Level E.
GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

The term “Activity” is often used interchangeably with Work Pack or
Work Package, however hub2 treats them as separate but equivalent.
The Activity is intended to represent the Planning Component and as
such represents a period of time utilised, rather than a physical
collection of documents.

Area

Physical space, usually used in conjunction with Module representing

Reference

part of a floor, an entire floor or even a whole building or structure,

Table

within a larger Asset or Facility.
As Built Drawings reflect what was constructed, rather than what was
As Built
Drawings

Documents

An association between a file and a database entry.

Documents

An entry in the Authorised Person reference table represents an

Reference

individual who is authorised to perform certain activities on a work

Tables

originally drawn; they are usually required when circumstances on
site required a deviation and are issued when Construction is
complete.

Attachment

Authorised
Person

scope. Within hub2 Authorised Person is used to record information
regarding the sign-off of a certification such as an ITR or PWL. Each
one can be linked to a user account through the Hub User ID field.

In simple terms Cables are collections of one or more lengths of

Tagged

electrically conductive materials that are contained within protective

Items

and non-conductive coatings. The coatings are commonly known as
‘Sheaths’. Each conductive-material-and-Sheath combination is
Cable

known as a Core.
It is possible that a cable may contain only a single Core, however it
is more likely that it will comprise multiple Cores contained within an
additional overall Sheath.

A means by which a collection of ITRs can be associated by

Reference

Discipline, Subsystem and Level E, the Certification Grouping is an

Tables

aliased entity (meaning the labels shown on page can be renamed
Certification from “Certification Grouping” to something else) that can be used to
Grouping
fill the role of a ‘Discipline Mechanical Completion (DMC)’ field, while
allowing project specific naming of that field.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Perhaps the easiest way to begin to describe a Discipline is to

Reference

provide some examples of it: Electrical, Mechanical, Safety, Fire &

Tables

Gas. These represent not only schools of knowledge to which an
individual might specialize in, or assume responsibility for, but also
categories of equipment or certification.
Discipline

Within hub2 the Discipline will be recorded against items such as
tagged equipment (Tags), Punch List Items and Inspection and Test
Records (ITRs). This can then be used to filter and subdivide
information, as well as to assign permissions and responsibilities to
authorised individuals, with the full details of these functions being
detailed in the relevant sections.

Drawings can cover a range of different types of illustration,

Reference

including Isometrics, Process and Instrumentation Diagrams and

Tables

General Arrangement Drawings amongst others. They serve to
Drawings

communicate information visually in a variety of ways, with the type
of drawing used determined both by convention and what is most
effective for serving the purpose required.

Equipment
Type &
Status

Equipment Type provides a way of categorizing Tags based on the

Reference

type of equipment. This can be useful in determining what type of

Tables

ITR should be assigned, something that is covered in more detail in
the Auto Allocation of Data section.
Equipment Status represents a further subdivision of this, and is an
optional attribute to enable greater granularity.

Equipment
Type to ITR
/ PWL

Allows ITRs and PWLs to be automatically assigned to a Tag based
on its Equipment Type.
Handover Certificates, usually referred to simply as ‘Handovers’ are

Reference

Tables
Handovers

Inspection and Test Records (ITRs) are records (traditionally paper-

Reference

based checklists, but increasingly available digitally) used to certify

Tables

used to guarantee Technical Integrity when responsibility is being
Handover

transferred between Authorities.
They’re explained in more detail in the Handovers section.

ITR

that tagged equipment has been properly built and tested in line

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

with agreed processes and procedures by approved and competent
personnel.
The ITRs (also referred to as check sheets, tally sheets and
certificates) include a list of tasks, measurements and activities that
should be completed to verify the status of the equipment
concerned.
While the design, content, naming and terminology of ITRs will vary
between different companies, locations and projects their ultimate
purpose is the same: To ensure the safety of equipment being
certified.

Job Card

Job Cards (also known as Job Packs) represent a further subdivision

Reference

of Work Packs and detail jobs to be undertaken at a facility. They

Tables

exist to authorise and instruct the workers to perform the listed task
and contain task guidelines, safety information and other relevant
documentation such as inspection procedures and drawings.

Line

Location

Loop

Mechanical
Joint

A Line is defined as a section of pipe. Lines can be connected via

Tagged

spools; a short section of pipe with fittings that allow one pipe line to

Item

connect to another. Like spools, lines can also be part of a test pack.

Location represents a physical space. This can be used to record the

Reference

position (either currently, previously or subsequently) of an object or

Tables

activity.

A Loop is an electrical circuit consisting of any number of electronic

Reference

components. Loops can be associated with Tags or Cables but not

Tables

any other tag-like object.

A connection established between two sections of pipe, using nuts

Tagged

and bolts. Factors such as the material used are critical in

Items

establishing the required tool and amount of force used to adjust the
nuts on joints, to ensure that no leak can occur, and that the nuts
and bolts are not under undue stress. Failure of a mechanical joint
could cause the fluid inside to leak. If this were a hydrocarbon (oil)
then the results could have serious consequences.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Management of Change is the process by which potential deviations

Changes

from original scope/design are tracked.
The MOC section may record queries being raised by site personnel
about deviations (e.g. if a piece of equipment is different than
MOC

expected) or instructions from the site (e.g. expect the equipment to
be different).
It’s essential that any such information is recorded for reasons of
safety and efficiency, as not properly bringing these issues to
attention could have hazardous consequences.

Reference

MOC Type

Module

Tables
The use of Module can vary: It may be used in conjunction with Area

Reference

to indicate a subdivision of the Area, such as a grouping of

Tables

equipment or a room on a floor, or alternatively may be used to
represent a vast physical component which is a major part of a
facility or asset.

Parent Tag

Phase

Priority

A Parent Tag is a grouping that can be used either to represent a

Reference

collection of Tagged Items that are related or that, when taken

Tables

together, constitute a larger functional object.

Phases provide a means by which a Level C can be subdivided into

Reference

distinct periods of time during which work will occur.

Tables

Priorities provide a means by which a Sub System or Secondary

Reference

Handover can be grouped together into specific tasks that will occur

Tables

during the same timeframe.

A Procedure is a set of logically sequenced instructions for the way

Procedures

of executing a class of activity. There can be many different types of
Procedure

Procedures with the main ones in hub2 being Commissioning
Procedures which is a Procedure with a step by step description of
activities required to commission an object.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Procedure
Section
Procedure
Step
Punch List

As with many other types of document, including this one,

Procedures

A Punch List is a grouping of Punch List Items.

Punch List

Punch Lists Items are used to record items of outstanding work

Punch List

Preservation involves tasks related to ensuring unused equipment is

Reference

kept in working condition. These tasks are often repeated on a

Tables

Procedures are commonly sub-divided into separate sections, which
in hub2 are represented via Procedure Sections entities.
Procedure Steps represent the actual activities associated with a
Commissioning Procedure. In this regard, they fill a similar role as a
task on an ITR.

which should have been completed previously. This could include
examples such as missing insulation or trace heating on pipework,
painting not complete or paint touch-ups required, outstanding
earthing of instruments or junction boxes, amongst many others.
Each of these examples could be raised as a Punch List Item (PLI).
Punch List Items are assigned a Punch List Category which is usually
used to indicate the severity of the defect. A common, and simple,
arrangement is to create two Punch List Item Categories, one with
the Name “A” and one with the Name “B”. Category “A” is used for
safety related defects, while “B” is used for others.
The ability to define Punch List Item Categories is however
Punch List
Item

completely at the discretion of the user and so may deviate
completely from the above example, which is provided for general
information only and does not constitute guidance on this subject.
Punch List Items also have a Scope. This Scope denotes what type of
Entity the Punch List Item refers to, with the following values
available:
•

Subsystem

•

Tag

•
•

Tag ITR
No Scope

When a PLI is considered complete by the person responsible for
undertaking the work it is reported as ‘Cleared’. After this, if it is
agreed by the responsible parties that the item is complete and
requires no further action it is ‘Accepted’.

PWL

regular schedule, to ensure the equipment is properly maintained
and ready to use when required.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Preservation is described in more detail in 8 Preservation

Spool

A short, prefabricated section of pipe, with fittings, that allow one

Tagged

pipe line to connect to another (possibly of different size).

Items

The fittings can include items such as Flanges (a plate or ring at the
end of a pipe), Elbows (used to change the direction of the pipe) and
Tees (three pipe connectors in a T shape), amongst others

Subsystem

System

A Subsystem is a functional object that represents a collection of

Reference

items that serve a common purpose. As with Systems, the items

Tables

themselves do not have to be physically connected.

A System is a functional object that itself is a collection of functional

Reference

objects (Subsystems) that form a network to provide a type of

Tables

service, or serve a common purpose. It’s worth noting that the
objects within a System do not have to be physically connected1.

In hub2 a Tag is a type of tagged-item that represents functionality

Tagged

provided by physical equipment within a facility, with the

Items

nomenclature arising from the equipment tag assigned (and usually
physically attached) to the equipment for identification purposes.
While this does mean that, taken literally, the tag is the label itself, it
is usually used to refer to the function of the equipment.
Tag

It should be noted that if a piece of equipment, or part of a piece of
equipment, is replaced this does not constitute a different tag.
Therefore, if Tag ‘A’ was a compressor with the Serial Number ‘0001’
and it down and was replaced with compressor with serial number
‘0002’, it would still be Tag ‘A’.

Tag ITRs represent an actual instance of an ITR (a check sheet used

Certification

to record test results) assigned to a tagged-item (such as a Tag,
which represents a piece of equipment, or a Test Pack which is a
Tag ITR

dossier of information representing a section of pipework to be
tested).
To explain this; imagine a project which hasa type of ITR called QEDE01A (an Electrical Check Sheet). When a user assigns an E01A type
ITR to a Tag then a new Tag ITR is created. If the user were to mark it

http://data.posccaesar.org/rdl/RDS316259

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

as complete, that Tag ITR would be updated, and if the user were to
remove it then the Tag ITR would be deleted. None of this would
affect that actual ITR itself, no matter what, QED-E01As would still be
available to assign to Tags.
As such it may be easier to think of the ITR Entity (which is described
in section 14 ITR) as the “library” of available Inspection and Test
Records, with the Tag ITRs being the actual assigned instances.

Just as a Tag ITR represents an actual assignment of an ITR to a Tag
Tag PWL

Preservation E

so does a Tag PWL represent a PWL to a Tag.
Preservation is described in more detail in 8 Preservation.
By viewing a E

Walk Down

Walk Downs are explained in more detail in the Handovers section,

specific
Handover
itself.

Work Packs (also called Work Packages, Construction Work Packs

Reference

and Construction Work Packages) are the lowest level represented

Tables

on a project’s Work Break Down structure (WBS) and are used as a
way of grouping tasks within a Work Scope (which, when following
recommended data population guidelines, maps to Level E of the
hub2 data structure).
Work Pack

In a literal sense, a Work Pack is a collection of documents necessary
for the completion of a group of tasks within the timescale specified
in the Project plan Activity. This will include Job Cards containing
details of Operations to be completed, corresponding Tag ITRs,
Drawings and details of the Equipment and Materials required to
complete them.

GoTechnology hub2 User Guide

For Authorised Users Ony. Do not distribute.

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.7
Linearized                      : No
Page Count                      : 40
Language                        : en-GB
Tagged PDF                      : Yes
XMP Toolkit                     : 3.1-701
Producer                        : Microsoft® Word for Office 365
Title                           : GoTechnology hub2 User Guide
Creator                         : Josh Goolnik
Creator Tool                    : Microsoft® Word for Office 365
Create Date                     : 2019:02:12 12:01:51+00:00
Modify Date                     : 2019:02:12 12:01:51+00:00
Document ID                     : uuid:0D6855EF-4976-412F-8385-1DD8AAB653EE
Instance ID                     : uuid:0D6855EF-4976-412F-8385-1DD8AAB653EE
Author                          : Josh Goolnik

EXIF Metadata provided by EXIF.tools

GoTechnology Hub2 User Guide

Navigation menu

Versions of this User Manual:

Views

Navigation