Administrator Journey

Overview

This journey describes the steps required for an administrator to set up an environment for AllAssets. Some of these steps are only required if the administrator wishes to create new content such as templates, lookups or models. AllAssets offers a wealth of engineering content out of the box, and administrators may find that what they need already exists.

Environment Preparation


The first step in preparing an environment in AllAssets involves defining the templates that are going to be used across the platform. There are different types of templates, each related to a specific part of the platform – these include hierarchy templates, inspection templates and events templates.

 

AllAssets comes with a range of pre-defined content, but the availability of this content is dependent on your company’s license and configuration. Pre-defined content includes:

  • Hierarchy Templates: 50+ (In both metric and SAE measurements)
  • Inspection Templates: 15+
  • Event Templates: 2+
  • Admin Lookups: 60+
  • Models:
    • Risk-Based Models: 30+
    • Maintenance Optimization Models: 5+

Templates, either pre-installed or user created, can be assigned to assets, inspections, or event records (As applicable) to organize and control the data entry process for these.

Units


The various units of measurement throughout the platform are defined in the Units application, under the Admin module.

Users can add new conversion factors to existing Units of Measure (UOM). Refer to the existing UOMs and conversions as examples.

Users can also define new units of measure by clicking on “New Unit of Measure”. Units of Measurement consist of a Name and a Category. After entering these and saving the new unit, you can define conversion rates between that unit and other units in the same category.; units can only be converted to those in the same category.

After the unit has been entered and saved, it can be used in areas of the software where inputs or outputs of that category are used.

Admin Lookups


Lookups are lists of connected data that can be used across the platform. These are defined in the Admin Lookups application, under the Administrator module.

Users can view details of the fields in the lookup in the Attributes panel.

Users can view the values in each row in the Values panel. In addition, if the lookup can be edited, they are able to edit the pre-assigned values and also add new rows, if required. After this, the user will need to Save the lookup, at which point it will be available for use elsewhere in the software.

In addition to editing existing information, users can create new Admin Lookups by pressing "New Lookup Item". A lookup is described by:

  • ID: this mandatory field is used as an identifier for the lookup
  • Label: this mandatory field is used to label the list of data
  • Description: This field is an optional description of the data


AllAssets will keep track of the Lookup version, status (draft or published) and who has created the lookup. If changes are introduced to the lookup, AllAssets will display who last modified the lookup and the corresponding date.

Once the mandatory fields are defined, users can Save the new lookup. They will then be able to add Attributes to the Lookup; users must add at least one attribute to the lookup.

To define an Attribute, the user must enter the following information:

  • Identifier: a mandatory field used to identify the attribute when it is referenced in a model
  • Label: a mandatory field which is used as the on-screen label for the attribute
  • Data Type: the type of data to be stored within the attribute; number, text, date / time, or boolean
  • Internal UOM : if data inside the attribute is to be in a particular unit, which unit that should be
  • Display Column : whether the attribute should be included in any dropdowns requiring the user to select a value from that lookup


After the attributes have been defined users can add as many data rows as necessary.

Hierarchy Templates


Hierarchy templates are used to capture data for different types of assets. For example, a boiler would require different data to be captured for it than a pressure vessel.

Users can edit existing templates by selecting them from the list view and altering their parameters. It is also possible to delete templates entirely, using the Delete button. It is important to note that:

  • Once a hierarchy template has been linked to an item in the hierarchy, it cannot be deleted.
  • Changes to the hierarchy template will be propagated to all items in the hierarchy that are linked to the template

Users can also create a new template, by clicking on the "New Hierarchy Template" button. When creating a new template, the following mandatory information must be defined:

  • Name: The name the template will be referred to as through the system.
  • Description: This field is used to describe what the template includes, its boundaries and its application
  • Asset Family: The type of equipment which this template will be able to be connected to

After saving the new template, the Attributes and Time Based Mitigations panels become available.

Attributes


Attributes are fields in the template where information can be stored and referenced.

Name: this is a mandatory field for the name of the attribute.

  • Type: this is a mandatory field where the user must select the attribute's type; number, text, date / time, boolean, and lookup (Admin Lookups can be defined in the Admin Lookup application, as abovearea at the Administrator Module). Following the same example as above, if the user has defined “Equipment Design Life” as an attribute, the type “number” must be selected to define the number of years
  • UoM: this is not a mandatory field and the user must select the Unit of Measure related to this attribute; Additional Units of Measure can be defined at the Units area at the Administrator Module. Following the same example as above, if the user has defined “Equipment Design Life” as an attribute, type “number”, the UoM “yr” must be selected to define the number of years
  • Tab Name: AllAssets allows users to organise the attributes into specific tabs; this data will be used to physically group items within the same tab.
  • Group Name: AllAssets allows users to group information within a specific tab; this configuration allows users to organize information


All this information can be edited at a later stage.

Inspection Templates


Inspection Templates are used to collect information that has been gathered through inspection activities. There are 19 inspection templates available for internal visual, external visual and relief device testing. If a company wants to collect inspection information not covered by the baseline content, the administrator needs to define what kind of attributes, observations and measurements should be collected as part of the task. All inspection reports include the following fields that don’t need to be added to the template: Inspection Date, name of Inspector, Inspection Confidence and Summary.

Users can also edit existing templates by selecting them from the list view and change their parameters. Deleting entire templates is also possible, users will have to select it and using the Delete icon. It is important to note that:

  • Once an Inspection Template has been linked to an item in the hierarchy, it cannot be deleted.
  • Changes to the Inspection Template will be propagated to all items in the hierarchy that are linked to the template.


Users can also create a new template, by clicking on “New Inspection Template”. When creating a new template, the following mandatory information must be defined:

  • Name: This is mandatory field will be used a display text across the platform.
  • Description: this mandatory field is used to describe what the template includes, its boundaries and its application
  • Asset Family: this mandatory selection will be used to filter templates per specific asset types.
  • Master Inspection Methods: this field is extremely important. AllAssets will create a list of Master Inspection Methods by identifying methods that are common across all recommendations available in the Mitigation Rules Engine. Once the administrator associates a Master Inspection Method to a template, AllAssets will check whether the Active Mitigation Plan for an asset has a specific method and, if this logic is true, it will automatically include the Task in the Mitigations table displayed in the Inspection Report. This step is extremely important because this information is used to retrieve the Last Inspection Date when the Mitigation Plan is updated. This information is also used to calculate the Due Date.

Attributes


Upon pressing save, the user must define the attributes. Three areas require information: Headers, Observations and Measurements.

Headers are best described as information that is relevant to the inspection but not necessarily related to the location or asset. One example of this would be the "Outside Temperature". Although at first glance this would seem like measurement is information pertinent to the inspection, not a direct measurement of the item being inspected. Headers are defined through two properties:

  • Name: this mandatory field refers to the attribute name (e.g. Insulated);
  • Type: this is a mandatory field where the user must select from the following types of attributes; Number, Text, Date and Time, Boolean (i.e. True and False statements) and Lookup (Admin Lookups can be defined at the Admin Lookup area at the Administrator Module). Following the same example as above, if the user has defined “Insulated” as an attribute, the type “boolean” must be selected to define a “True” or “False” statement

Observations fall into two categories. Observations that only require a yes/no response, or those observations that have a condition-based response. An example of a yes/no observation would be "Visible Leaks". An example of a condition-based observation would be "Coating Condition". Condition-based responses are "Good, Fair, Poor, N/A" and are subjective based on the user's opinion. Observations are defined as:

  • ID: which services as an identifier for the observation
  • Description: describes what must be observed as part of the inspection (e.g. Coating Condition)

When an inspection report is created, the following columns are displayed for each observation:

  • Condition: user selects from the following choices: Yes, No, Good, Fair, Poor, N/A
  • Location: description of a physical location or reference to area on an attached drawing
  • NCR: Nonconformance Report is an attribute for customers migrated from legacy product
  • Comments: additional details from inspector
  • Events: enables creation of new Event records or viewing Events

Measurements are mathematical values captured to help understand the health of an asset or the context of the inspection. Thickness measurements should be recorded in Thickness Reports so AllAssets can calculate corrosion rates and remaining life. Measurements are defined by:

  • Name: this mandatory field refers to the attribute name (e.g. Insulated).
  • UoM: this is not a mandatory field and the user must select the Unit of Measure related to this attribute; Additional UOMs can be defined at the Units area at the Administrator Module. Following the same example as above, if the user has defined “Equipment Design Life” as an attribute, type “number”, the UoM “yr” must be selected to define the number of years.

All this information can be edited at a later stage.

Event Templates


Event Templates are used to describe problems found during an inspection, so Event records are related to a specific Observation in an Inspection Report.

Two Event Templates (Non-Conformance and Repairs) are provided depending on your company’s license and configuration of AllAssets. Users can edit existing templates by selecting them from the list view and change their parameters. Deleting entire templates is also possible, users will have to select it and using the Delete icon. It is important to note that:

  • Once an Event Template has been linked to an Inspection Report, it cannot be deleted.
  • Changes to an Event Template will be propagated to all Event records using this template.

Users can also create new Event templates, by clicking on “New Event Template Item”. When creating a new template, the following mandatory information must be defined:

  1. Name: This field will be used as a display text across the platform.
  2. Description: This field is used to describe what the template includes, its boundaries and its application
    Process: This fields identifies which set of stages will be available

Upon pressing save, the Attributes area becomes available.

Attributes


Attributes are effectively data fields in the database where information can be stored

  • Name: this is a mandatory field referring to the attribute name.
  • Type: this is a mandatory field where the user must select from the following types of attributes; Number, Text, Date and Time, Boolean (i.e. True and False statements) and Lookup (Admin Lookups can be defined at the Admin Lookup area at the Administrator Module).
  • UoM: this is not a mandatory field and the user can select the Unit of Measure related to number attributes; Additional Units of Measure can be defined at the Units area at the Administrator Module.
  • Process Stage: AllAssets allows users to organise the attributes into specific stages which will be displayed as tabs. Additional Processes and their stages can be defined by clicking the “Processes” button in Event Templates.
  • Group Name: AllAssets allows users to group information within each stage; this configuration allows users to organize information.
  • Order: Event attributes can be organized within each Group by defining a numerical order starting with 1 up to the number of attributes within the same Group.

All this information can be edited at a later stage.

Models


Depending on your license, several models will be included in the content of AllAssets. Users can explore and configure these models in the Models area of the Admin Module. Upon selecting one of the models using the hyperlinked text at the Name column, users will see all the properties used to create a model in AllAssets.

In this menu, it is possible to:

  • Define which model attribute is used for Analysis Date in Risk Analysis to support Mass Criticality What-if scenarios for a future date.
  • Define which model attribute determines the Estimated Half-Life in Risk Analysis to support Override Frequency in Mitigations.
  • Map Hierarchy Templates to Models so once a model is linked to an asset in the hierarchy, data is transferred from the hierarchy template to the model.
  • Review, append or replace Mitigation strategy rules that provide recommendations in the Mitigations application based on the outputs of a model.
  • Configure Risk Matrix to display the output of a risk-based model
  • Define which Units of Measure will be displayed on the screen which may be different than the UOM used when the RBI model was created

Security


Administrators with access to the Security application can create new users, access roles, and groups.

To create a new user, go to the Users application under the Security module. Press the "New User Item" button to create a new user account, and then populate the following details:

  1. Sign-On Provider: This selection determines whether the user will log in via an AllAssets account and password, or using their network's Active Directory login.
  2. Username: This is the user name they will use on the login page. For Active Directory login accounts, it needs to be the same as the user's Active Directory account.
  3. Name and Surname: The new user's name
  4. Email: The new user's email address
  5. Password: The new user's login password. They will be prompted to change this the first time they log in.
  6. Verify Password: Enter the same password from the Password field here.

 

Once these details have been filled out, the administrator can press Save to record the new account to the database. However, they will need one or more roles configured in order to actually do anything in the software.

To do this, go to the Roles application under the Security module. Press the "New Role Item" button to create a new role, and then give the role a name and description.

Then go to the Permissions tab, and assign permissions to the new role. Permissions in the hierarchy need to be selected explicitly; selecting a permission at the top of the tree will not select permissions below it. Once you have Saved the role, you are able to add it to the user on the Users page.


Preparing the Asset Hierarchy

Organizations


An “Organization” is the highest level of a Hierarchical Tree. So, before starting to set up your AllAssets environment, this information must be provided; if you don’t have all the required information, you can edit these fields at a later stage. The following fields are mandatory and the “Save” button will only be enabled once the user has added all the following details:

  • Name
  • Description
  • Address Line 1
  • Address Line 2
  • Locality
  • Region
  • Country
  • Post Code
  • Phone Number


Upon adding all the information, you can save the new data and your “Organization” is set up.

In addition to defining the attributes, users can set up the connection to Enterprise Resource Planning tools.

ERP Settings


The ERP Connector is an additional licensed module in AllAssets and it may require configuration. So, if you would like to enable AllAssets to synchronise with your ERP tool, please contact our support team. Also, setting up the ERP connection is typically performed by an ERP specialist. Upon clicking on “ERP Settings”, another window will pop-up requiring further information.

The following information is required to set up the ERP connector:

  • Organization reference: Enter the “organization” in the ERP system to map to the AA organization – if only one entry exists, a constant value can be used.
  • ERP System: Select an option from the drop-down list to specify the type of ERP system the API will connect to, Maximo or SAP.
  • Notifications / Work Orders: Select from the drop-down list what will be created in the ERP system from mitigation plans, Notifications or Work Orders. For Maximo, the only valid option is Work Orders.
  • Parent Mapping Enabled: Mark the checkbox to include the parent as part of the field mappings. When enabled, the target asset or location being synchronized will have its parent defined by the ERP system. Otherwise, any new asset or location will be installed by default in the ERP HOLD location under the proper site. The user will then have to manually update the parent accordingly.
  • Email: Enter the default email to be used for info and error email notifications.
  • URL: Enter the root URL of the REST APIs. The API endpoints are predefined and must be set accordingly.
  • Username: Enter the username for basic authentication.
  • Password: Enter the password of the username.
  • Synchronization Scheduling: Select one of the options to enable the scheduler to run at the desired interval or select None to disable it. Note, the scheduler will be applied to all the sites-enabled for ERP.
  • Test Connection: Click to test the connectivity to the API.
  • Synchronize Now: Click to execute the interfaces manually – this will not interfere with the scheduler if enabled. Note, the interface will be run for all the sites-enabled for ERP.

Sites


An “Organization” is formed of one or many sites. A Site is also the second level in the Hierarchy Tree – the following list includes the information required to define a site:

  • Name: this is the only mandatory field
  • Description
  • Address Line 1
  • Address Line 2
  • Locality
  • Region
  • Country
  • Post Code
  • Phone Number


Finally, two attributes important to the Mitigation recommendation process must be defined at the Site level. After a driving scenario is saved in Risk Analysis, AllAssets will provide mitigation Recommendations based on outputs of the model including a task frequency that establishes the periodicity of the task. If a setting for a recommended task allows, the Mitigation application determines an override frequency from four possible sources and two of these are controlled by settings for the Site; Thickness Half-life and Criticality Half-Life. These Site settings are defined as:

  • Thickness Half-life Override: The Thickness Half-Life is based on the actual reading data from thickness reports. This is defined as half of the Remaining Life calculation which is displayed at the Evaluation tab from Thickness Report. The thickness half-life is more accurate than the estimated half-life, however, the user needs to input data to ensure it is calculated properly. Moreover, its accuracy will be dependent on the data collected in the field.
  • Criticality Half-life Override: Criticality Estimated Half-Life is the estimated half-life based on the input data from RBI internal corrosion. The calculation uses the following parameters:
    • Actual thickness (i.e. t-actual) which is the Estimated Wall Remaining
    • Required thickness (i.e. t-required) which is Estimated Minimum Thickness
    • The corrosion rate selected by the user; this parameter could be Expected, Short-Term or Long-Term

These two properties must be enabled here, at the Site level. If the user chooses to enable these features, AllAssets will calculate both, in addition to the recommended frequency coming from the Mitigation Rules. AllAssets will then use the lowest frequency - if thickness readings are not entered in AllAssets then Thickness Remaining Life will not exist, so we provide Criticality half-life as an alternative. However, once Thickness readings are entered the Criticality half-life will be ignored because thickness readings are assumed to be more accurate.

The administrator can also define ERP settings:

  • Site reference: Enter the “site” in the ERP system to map to the AA site.
  • Use Organization Connection Settings: Mark the checkbox to inherit the ERP settings entered for the organization. Otherwise, the remaining ERP settings must be entered and will be localized to the site.
  • Synchronize Now: Click to execute the interfaces manually – this will not interfere with the scheduler if enabled. Upon defining the highest level of the hierarchy, the user can move into defining hierarchy.

Note, the interface will be run only for the site.

Hierarchy Tree


Once the Organization and Sites have been defined, the user can create the Hierarchy Tree either by manually creating Hierarchy Items one-at-a-time or, if the user has Administrator privileges, they can be created in bulk using the Data Uploads area of the Administrator Module.

In this area, the user must select the “Locations, Assets, Components, Parts” option from the dropdown list.

This selection will enable the next dropdown where the user selects the Site to which the data needs to be uploaded. Once the Site is selected, AllAssets will create an empty template including several pre-defined parameters for this specific site and then users can download a template to guide them on how to enter the data.

For the “Locations, Assets, Components, Parts” upload process, AllAssets will verify if the items exists. It will perform this check by looking at the asset address using the Parent Name and Parent Location. Two potential outcomes:]

  1. If the Asset doesn’t exist, AllAssets will create a new asset
  2. If the asset exists, the data will be updated with the new asset information described in the row

Data Uploads has been designed to upload data through layers. This means that users should start by importing top-level locations and move gradually down the tree. For example, if the following tree is to be uploaded:

  • Site
    • Location 1
      • Location 1-1
        • Asset 1-1
    • Location 2
      • Asset 1
    • Location 3

The upload file should have 3 levels described in different tabs:

  1. Tab 1: it should contain information about Level 1 (i.e. Location 1, Location 2, Location 3)
  2. Tab 2: it should contain information about Level 2 (i.e. Location 1-1, Asset 1)
  3. Tab 3: it should contain information about Level 3 (i.e. Asset 1-1)


Once the tree has been defined, users can start populating the hierarchy templates.

Hierarchy Attributes


In the same area, Data Uploads in the Admin Module, the user selects the “Hierarchy Item Attributes” option from the dropdown list. The next step is selecting the Hierarchy Template which you want to focus on the data upload process. Users can download a template to guide them through the upload process. This feature is very useful because it will download all attributes defined in the Application and indicate what type of data must be entered in each column.

For the “Hierarchy Item Attributes” upload process, AllAssets will verify if the hierarchy item exists before populating the Hierarchy Template. It will perform this check by looking at the asset address using the Parent Name and Parent Location. Two potential outcomes:

  1. If the asset does not contain Hierarchy Template data, AllAssets will create and add the new data to the asset
  2. If the asset contains Hierarchy Template data, AllAssets will update the existing asset data

This step is optional but very important in the process for companies that are using Risk-Based Inspection Models, AllAssets will use the Hierarchy Item Attributes to populate the risk model with the initial information. Every RBI model has Hierarchy Templates mapped to them so data does not have to be entered twice. However, this synchronisation works only once when a model has been linked to the asset. It is important to note that if new hierarchy templates or models have been created, the new templates need to be mapped to new models before items are linked to the new models.

Model Linking


The process of linking models is carried out at the Link Models area in the Manage Equipment module. Users should start by selecting a model from the table presented – it is possible to enable column filtering capability by clicking on the Filter button at the top right.

Upon selecting the model by clicking on the hyperlinked model name, AllAssets will display another table. This table will show what hierarchy items are currently linked to this model and it will also allow users to select new items to link to this model. This selection is done by clicking on the radio button.

These steps are applicable for both Maintenance Optimisation and Risk-Based Inspection models. Administrators can edit this link until the first time a model has been run or a maintenance model has been activated. If one of these tasks have been performed, the link button will be greyed out and users will not be able to edit this selection again.

Models can be adapted to replicate specific conditions. Users and/or Pinnacle can edit the models so it includes the recommendations and nuances to the risk calculations that are necessary to properly represent the users’ risk profile.

This journey assumes that all models have already been defined and the only step required from the administrator is to define the risk matrix. This step is explained in detail in the next section.

Defining a Risk Matrix


The Administrator module gives the user the ability to create a Risk Matrix to be used in both Risk-Based Inspection Calculations and Failure Mode, Effect and Criticality Analysis.

The administrator can add a new risk matrix by clicking on the “+” button at the top right. The administrator is expected to provide the following details:

  • Name: this mandatory field is used as a display name when associating a risk matrix to a model
  • Description: This optional field can be used to describe the context in which the risk matrix is being used.
  • CoF and PoF: administrator designates independently whether consequence and probabilities are displayed in ascending or descending order from the bottom left corner of the matrix and extending along the designated dimension (i.e. axis). This information can be edited later.

Once this information has been added, a new button will be enabled allowing users to manipulate information for this risk matrix. To fully describe a risk matrix, users are expected to define:

  • Dimensions: these fields determine the size of the risk matrix by defining the number of rows and columns.
  • Consequence: this field defines whether the consequence axis will be displayed in columns or rows of the matrix. The Probability will be displayed in the dimension not selected for Consequence.
  • Consequence and Probability: administrator can edit independently whether consequence and probabilities are displayed in ascending or descending order from the bottom left corner of the matrix and extending along the designated dimension (i.e. axis).
  • Risk Bands: risk bands are assigned to each colour in the risk matrix.
  • Is Default Risk Matrix: this field designates the primary risk matrix used across the environment; this choice will influence, for example, the dashboards which are going to use the default risk matrix to plot risk calculation data.
  • Step Up Probability Category: This drop-down list displays a list with the current risk matrix probability information. Upon selecting one of these values, the user is indicating that the model overall PoF value will be incremented by one when more than one damage mechanism has the same PoF. Currently, the incremented overall PoF value is implemented in AllAsset’s single-component model and child component models.

Once the Risk Matrix is displayed, each axis and the boxes within the matrix can be labelled. RBI models use the box numbers as Inspection Priority Numbers to filter the Mitigation strategy rules. By clicking the paintbrush icon, each box can then be colored to match the corresponding Risk Band.

For the Risk-Based Inspection models, this feature is mapped to Strategy Rules for recommended inspection tasks and risk calculations. As discussed, it enables users to customize the default Matrix configuration settings to allow the assumption of risk.