NOTE TO OUR SUPPLIERS

Digital Engineering is presently in the process of revising our existing procedures for asset information
requirements. This document serves as a guideline, and suppliers are encouraged to collaborate closely
with KiwiRail's DE team regarding ongoing projects' asset information needs. We will notify all our suppliers
once the updated version is finalized and made available. Thank you.
 Digital Engineering
Asset Information Requirements
Version 1

1 | © KiwiRail Digital Engineering Asset Information Requirements

 Document Control
Version History

Version Number Version Date Summary of Changes Author

Anna Whitmore, Andrew
1.0 03 June 22 Initial publish for project use
Shakes, Josh Bradfield

Reviewers’ Name

Reviewer Name Date Signature Position

D Jannings 7 June 2022 Digital Engineering Programme Manager

D Roberts 8 June 2022 Asset Information Manager - Network

Signed off by Approvers

Approver Name Date Signature Position

A Lyon 17 June 2022 Programme Director – Digital Engineering

Final Distribution

Name Position

File -

2 | © KiwiRail Digital Engineering Asset Information Requirements

Contents
1 Introduction ......................................................................................................................................... 5
1.1 Purpose ........................................................................................................................................... 5
1.2 AIR outcomes .................................................................................................................................. 5
1.3 Audience ......................................................................................................................................... 5
1.4 Terminology ..................................................................................................................................... 5
1.5 Terms and Definitions ...................................................................................................................... 5
1.6 Future Updates ................................................................................................................................ 5
1.7 References ...................................................................................................................................... 6
1.8 Information standards ...................................................................................................................... 6
1.9 Framework Documents .................................................................................................................... 6
2 Asset information concept overview ................................................................................................. 9
2.1 Information models .......................................................................................................................... 9
2.1.1 Project Information Model (PIM).................................................................................................. 9
2.1.2 Asset Information Model (AIM) .................................................................................................. 10
2.2 How is asset information used? ..................................................................................................... 11
2.2.1 Asset Information Types ........................................................................................................... 12
2.2.2 Common Data Environment (GeoDocs) .................................................................................... 12
3 Asset data requirements ................................................................................................................... 14
3.1 What information is required? ........................................................................................................ 14
3.1.1 Asset classification information ................................................................................................. 14
3.1.2 Asset Location information ........................................................................................................ 15
3.1.3 Unique Identifier ........................................................................................................................ 16
3.1.4 Asset naming conventions ........................................................................................................ 17
3.1.5 Asset labelling convention......................................................................................................... 17
3.2 Information Delivery ....................................................................................................................... 17
3.2.1 Data structure ........................................................................................................................... 17
3.2.2 Quality assurance ..................................................................................................................... 18
3.2.3 Exchange milestones ................................................................................................................ 18
4 Asset documentation requirements ................................................................................................. 19
4.1 What information is required? ........................................................................................................ 19
4.1.0 Asset operations information ..................................................................................................... 19
4.1.1 Health, safety and risk .............................................................................................................. 19
4.1.2 Design and as-builts ................................................................................................................. 20
4.1.3 Construction, commissioning and testing .................................................................................. 20
4.2 Information Delivery ....................................................................................................................... 20
4.2.1 Format ...................................................................................................................................... 20
4.2.2 Exchange milestones ................................................................................................................ 20
5 Geometric information requirements ............................................................................................... 22
5.1 3D models ..................................................................................................................................... 22
5.2 Geospatial information ................................................................................................................... 22
5.2.1 What information is required? ................................................................................................... 22
5.2.2 Information Delivery .................................................................................................................. 23
3 | © KiwiRail Digital Engineering Asset Information Requirements
 5.3 2D drawings................................................................................................................................... 23
5.4 Point Cloud & LiDAR ..................................................................................................................... 24
6 Appendices ........................................................................................................................................ 25
6.1 Appendix A: Terms and Definitions ................................................................................................ 25
6.2 Appendix B: Document Type Code List ......................................................................................... 28
6.3 Appendix C: Discipline Code List ................................................................................................... 29
6.4 Appendix D: Linear Referencing Requirements ............................................................................. 30
6.4.1 Deriving Linear references ........................................................................................................ 30
6.4.2 Interim conversion requirements ............................................................................................... 30
6.5 Appendix E: GIS Attribution ........................................................................................................... 31
6.6 Appendix F: Discipline 2D Drawing Requirements ......................................................................... 36

Tables
Table 1: Digital Engineering Documentation ................................................................................................. 8
Table 4: GIS Metadata Requirements......................................................................................................... 23
Table 5: 2D drawings naming convention ................................................................................................... 23

Figures
Figure 1: Digital Engineering Document Structure ........................................................................................ 7
Figure 2: The Project Information model (PIM) ............................................................................................. 9
Figure 4: Asset Management activities inform asset information requirements ........................................... 10
Figure 5: The Asset Information Model ....................................................................................................... 10
Figure 6: KiwiRail Enterprise Asset Information .......................................................................................... 11
Figure 7: KiwiRail personas ........................................................................................................................ 11
Figure 8: Asset Information Types .............................................................................................................. 12
Figure 9: Project Information workflow through KiwiRail Systems ............................................................... 13
Figure 10: Asset Classification Example ..................................................................................................... 14
Figure 11: Example attributes required for Turnout Asset Classification ..................................................... 15
Figure 12: Example Functional Location ..................................................................................................... 15
Figure 13: Linear Reference example ......................................................................................................... 16
Figure 14: Unique Asset Identification flowchart ......................................................................................... 17

4 | © KiwiRail Digital Engineering Asset Information Requirements

1 Introduction
This document defines KiwiRail’s Asset Information Requirements (AIR) which shall be applied in the
production and delivery of asset information for KiwiRail.
This section sets out the purpose of the AIR and provides background and context.

1.1 PURPOSE
The purpose of this AIR is to define what asset information is required at project completion, to improve
how as-built information is captured and managed.
The AIR aligns with the following DE Programme objective:
Provide information to everyone - democratise data (e.g. technical design models, laser scans) and drive
data-based decision making across the CPAD portfolio, and in turn the wider business.

1.2 AIR OUTCOMES

By defining what asset information is required and how it shall be delivered, KiwiRail will achieve the
following outcomes:

• Providing the supply chain with a clear scope for asset handover information to support an accurate
tender process

• Ensure the right information is captured, stored and accessible in KiwiRail systems to support day
one asset operation
• Increase the quality of asset information to improve asset management decision making
• Create the foundations for a future digital twin by capturing quality asset information

1.3 AUDIENCE
This AIR must be adopted by all task and delivery teams when managing information within a digitally
enabled project.
The language and terminology used within the AIR is suited to project delivery professionals as the
information required to be handed back is technical in nature.

1.4 TERMINOLOGY
This section articulates the ‘language’ of compliance. The following terms have defined meanings.
• must – describes a legal requirement
• shall – describes mandatory requirements of the standard;
• should – describes non-mandatory, best practice recommendations
• may – describes possible options that are neither mandatory nor best practice.

1.5 TERMS AND DEFINITIONS

For terms and definitions outlined in this document refer to Appendix A: Terms and Definitions.

1.6 FUTURE UPDATES

KiwiRail recognises that this AIR is a first release and includes some inconsistencies which will be
addressed in future versions. KiwiRail welcomes feedback from users of the document.
The current workstreams in development include:
1. Asset information hand back toolset – to transform the process for defining and capturing asset data
during project delivery.

5 | © KiwiRail Digital Engineering Asset Information Requirements

 2. Reconciliation of the required asset data attribution and GIS attribution
3. Information Delivery Plan Template – to standardise how asset information shall be delivered

1.7 REFERENCES
The AIR relies upon the information requirements collated from the following KiwiRail business units:

• CPAD – Capital Projects and Asset Development

o Asset management
o Digital Engineering
• Operations
o Engineering Services
o Network Services
In addition to these, it should be recognised that the AIR forms part of a larger document suite, and may
draw reference to other relevant standards, requirements, specifications, or guidelines included in Table 1.

1.8 INFORMATION STANDARDS

The following standards shall be adopted during the production and exchange of asset information:
1. ISO 19650-3:2020 – Organization and digitization of information about buildings and civil
engineering works, including building information modelling (BIM). Information management using
building information modelling – Part 3: Operational phase of the assets.
2. ISO 19650-5:2020 - Organization and digitization of information about buildings and civil
engineering works, including building information modelling (BIM) — Information management using
building information modelling — Part 5: Security-minded approach to information management
3. ISO 16739 - Industry Foundation Classes (IFC) for data sharing in the construction and facility
management industries

1.9 FRAMEWORK DOCUMENTS

The KiwiRail DE Framework is a suite of documents as shown in Figure 1 and described in Table 1. This
enables technical information to be covered in a specific document, for the right audience. The following
two documents should be read in conjunction with this AIR:
• The Digital Engineering Information Standard Part 2: Information Production framework
document provides additional guidance on the development of asset information.
• The KiwiRail Information Delivery Plan (IDP) provides a template for identifying project-specific
information deliverables. The IDP sets out when information is to be prepared, by whom, and
following what protocols and procedures for each delivery stage.

6 | © KiwiRail Digital Engineering Asset Information Requirements

 Figure 1: Digital Engineering Document Structure

7 | © KiwiRail Digital Engineering Asset Information Requirements

Table 1: Digital Engineering Documentation

Document Purpose

Enterprise

Digital Engineering Framework To outline KiwiRail’s DE vision and overarching objectives.

To provide guidance as to where specific detail can be found in other documentation.

Digital Engineering Information Outlines the process of how information is managed and consumed within the context of a
Standard – Part 1 project.
(Management)

Digital Engineering Information Outlines the details of how information should be produced by an author to meet KiwiRail’s
Standard – Part 2 (Technical) information requirements.

Subsurface Utilities Identification How to identify, model and transmit subsurface utility information to KiwiRail within a project.
and Modelling Guidance Note

3d Spatial Data Capture Outlines how spatial information is to be captured, created, reference, and controlled.
Framework

Asset Data Dictionary Outlines all the possible asset types, and their associated attribution requirements.

GeoDocs Guidance Note Supplementary document which covers off the correct usage of the CDE, including details of
the background processes for those wanting additional detail.

Revizto Guidance Note How KiwiRail standardise the use of Revizto across the KiwiRail projects portfolio.

Digital Design Management Outlines how the DE tools & processes of KiwiRail’s DE Framework can be embedded within
Guidance Note the design phase of a capital project to support & enable design management fundamentals.

Project

Digital Engineering Execution Outlines how Digital Engineering will be completed throughout the scope of the engagement,
Plan (DEXP) responding to the requirements outlined in the EIR.
Outlines the roles and responsibilities within the supplier’s organisation and can be used as
a form of assessment for the tender submission process.
Pre-contract is to be prepared by the supplier, and the post-contract is collaboratively
developed between KiwiRail, its partners and the supplier.

Project Information Protocol Provides additional clauses which enable the scope of Digital Engineering to be amended to
the contract.

Information Delivery Schedule Details the level of information need, required against asset data dictionary classifications,
throughout the project lifecycle.
Specifies the types of asset classifications expected throughout the scope of the project.

Project Information Includes general project information, including scope, stakeholders and high-level delivery
Requirements (PIR) milestones.
Outline the overarching project specific digital initiatives for implementation on the project.

PIR explain the information needed to answer or inform high-level strategic objectives within
the appointing party in relation to a particular built asset project. PIR are identified from both
the project management process and the asset management process. (extract from ISO)

Exchange Information Breaks down the overarching project objectives in the Project Information Requirements into
Requirements (EIR) the requirements of each engagement within a project at a detailed level.

Details the expectations of information delivery against the project milestones.

EIR set out managerial, commercial, and technical aspects of producing project information.
The managerial and commercial aspects should include the information standard and the
production methods and procedures to be implemented by the delivery team. (extract from
ISO)

8 | © KiwiRail Digital Engineering Asset Information Requirements

2 Asset information concept overview
This section describes Digital Engineering concepts, asset information types, how information is used
across KiwiRail and the core asset information systems.

2.1 INFORMATION MODELS

There are two forms of information model being the Project Information Model, and the Asset Information
Model.

2.1.1 Project Information Model (PIM)

The Project Information Model is delivered through two stages. The first stage is the Design Intent Model,
and second is the Virtual Construction Model which is used for the fabrication/construction of the asset.
Figure 2: The Project Information model (PIM) illustrates the types of information that contributes to the
PIM.

Figure 2: The Project Information model (PIM)

9 | © KiwiRail Digital Engineering Asset Information Requirements

2.1.2 Asset Information Model (AIM)
The Asset Information Model (AIM) comprises of the completed Project Information Model (PIM), alongside
information required for operations and maintenance, when all compiled within the KiwiRail asset
management systems. The AIM specified supports the strategic and day-to-day asset management
activities.

Figure 3: Asset Management activities inform asset information requirements

Figure 4: The Asset Information Model

10 | © KiwiRail Digital Engineering Asset Information Requirements

 Figure 5: KiwiRail Enterprise Asset Information

Further information on the AIM and PIM is defined in the Digital Engineering Information Protocol.
The project specific PIR and KiwiRail AIR (this document) are distilled into Exchange Information
Requirements (EIR). PIR and EIR Guidance and templates are available on the KiwiRail Digital
Engineering website.

2.2 HOW IS ASSET INFORMATION USED?

Asset information is consumed across the KiwiRail by different teams for different activities. The
requirements detailed in this AIR were informed by the wider business, who are the end recipients of the
information handed back from a project. Figure 6 describes how different roles across KiwiRail use asset
information for decision-making across a range of use cases.

Figure 6: KiwiRail personas

11 | © KiwiRail Digital Engineering Asset Information Requirements

2.2.1 Asset Information Types
There are different types of asset information that contribute to the Asset Information Model (AIM). Asset
information has been grouped into the three types as shown in Figure 7.

Figure 7: Asset Information Types

This document is structured based on these three information types, outlining what information is required
and how it should be produced.

2.2.2 Common Data Environment (GeoDocs)

The KiwiRail Common Data Environment (CDE) creates a central source of truth for project information.
The benefits of a CDE include streamlined processes, improved collaboration, and reduced rework.
All asset information handed back to KiwiRail should be transferred via the GeoDocs CDE. The KiwiRail
Digital Engineering team will work collaboratively with the different business units to transfer the information
into specific systems. This ensures all project information is stored on KiwiRail systems and mitigates the
risk of incomplete information hand back.
Figure 8 provides an overview of information flows from the project teams, through the KiwiRail CDE and
into the relevant operational business systems.

12 | © KiwiRail Digital Engineering Asset Information Requirements

Figure 8: Project Information workflow through KiwiRail Systems

The KiwiRail Common Data Environment (CDE) for Capital Projects Delivery is GeoDocs. Detail on the
GeoDocs CDE can be found in the Digital Engineering Framework and GeoDocs Guidance Note.

13 | © KiwiRail Digital Engineering Asset Information Requirements

3 Asset data requirements
This section provides an overview of the asset data required prior to practical completion. At the time of
publishing AIR Version 1.0, KiwiRail are developing an asset information hand back toolset. The purpose of
the toolset is to improve the identification, exchange, and validation of asset data from the supply chain.

3.1 WHAT INFORMATION IS REQUIRED?

To support the efficient operation of KiwiRail assets, complete and accurate asset data must be captured
and managed in KiwiRail Asset Information Management Systems.
All asset data shall be provided according to the KiwiRail Data Dictionary which has been informed by the
KiwiRail asset management and maintenance teams. The KiwiRail Data Dictionary is an established
hierarchy of asset information and defines a common language for identifying and classifying KiwiRail
assets and spaces.
The KiwiRail Definition Viewer prescribes the attributes required for KiwiRail assets, aligned to the Data
Dictionary.
The following sections provides an overview of the key asset information concepts within KiwiRail.

3.1.1 Asset classification information

Every KiwiRail asset has an assigned classification which determines what attribution is required for the
asset. Each new asset delivered to KiwiRail must include the corresponding asset classification and
required attributes. Figure 9 illustrates an asset classification example.

Figure 9: Asset Classification Example

3.1.1.1 Classification attributes

Asset attributes provide crucial information required for operations and maintenance. Figure 10 provides an
example of some attributes required for assets classified as a Turnout.

14 | © KiwiRail Digital Engineering Asset Information Requirements

 Figure 10: Example attributes required for Turnout Asset Classification

3.1.1.2 Uniclass Application

The Uniclass 2015 classification system, published by the National Building Specification (NBS), is a
unified classification system for the built environment. The KiwiRail definition view provides Uniclass
definitions where identified. Uniclass classifications should be defined for the first two hierarchy levels:
• Systems (Ss) Uniclass tables
• Product (Pr) Uniclass tables
Where a Uniclass classification is not available the KiwiRail Digital Engineering team should be informed
and will provide a classification.

3.1.2 Asset Location information

3.1.2.1 Functional Location Type

A Functional Location describes an item in which other assets are operated, stored or repaired. A
functional location has a one-to-many relationship with assets i.e. a functional location may contain multiple
assets, but an asset can only be in one functional location.

Figure 11: Example Functional Location

3.1.2.2 Linear reference

Linear referencing describes the position of an asset, event, or other asset information in relation to a linear
asset. It may also be referred to as ‘chainage’, ‘meterage’ or ‘kilometerage.’ A linear reference can be
expressed as an absolute measure (a distance along the linear asset from its origin) or as a relative
reference (a distance along the linear asset from a reference point, whose position is also related to the
origin of the linear asset).

15 | © KiwiRail Digital Engineering Asset Information Requirements

For railway use, the reference point is typically a marker post adjacent to the railway. The relative
reference form is similar to a street address for railway tracks and is the most commonly used form. There
are four components of a relative linear reference:

• Line refers to the named rail corridors and is often abbreviated, e.g. North Island Main Trunk is
abbreviated to the code NIMT.
• Track is used, where required, to position the asset or object relative to a specific track where there
are two or more tracks running parallel.
• Reference Point is the known point from which the distance to the position of interest is measured.
The reference point will always be a physical object and in most cases will be a Kilometre Post (‘km
post’) adjacent the railway line. Note that km posts might not be spaced 1000m apart.

• Offset is the measured distance, in metres, from the reference point to the position of interest.

Figure 12: Linear Reference example

When using a km post as the reference point, the offset is usually represented as a 3-digit decimal fraction
of a kilometre, for example NWMKT 120.980 is 980 metres past km post 120 on the Newmarket line, or
with a plus sign instead of the decimal, e.g. NWMKT 120+980. Because both the decimal and plus form
can cause confusion, reference point and offset must be provided in separate data fields.
Linear references can be converted to and from spatial coordinates. Guidance on how to derive linear
references and convert between spatial coordinates is included in Appendix D: Linear Referencing
Requirements.

3.1.3 Unique Identifier

Every asset shall have a unique identifier to provide a link between the asset and related graphical models,
asset data, and documentation.
An asset identifier will be generated by the KiwiRail asset data hand back toolset at asset conception and
serve as the primary key for the duration of project delivery. At asset handover the project asset identifier
will be superseded by the KiwiRail asset identifier assigned in IBM Maximo.

16 | © KiwiRail Digital Engineering Asset Information Requirements

 Figure 13: Unique Asset Identification flowchart

3.1.4 Asset naming conventions

At the time of developing this AIR there is no overarching KiwiRail asset naming convention. Certain asset
classifications have defined naming conventions, e.g. Turnouts and Signals. Where defined, the
conventions shall be followed and include in asset data in the Name Description attribute field.

3.1.5 Asset labelling convention

At the time of developing this AIR a KiwiRail asset labelling convention is under development. This will
pertain to the physical labelling of the asset and is not considered within the scope of the AIR.

3.2 INFORMATION DELIVERY

The KiwiRail Digital Engineering Information Standard Part 2: Information Production provides details
on how asset data should be produced. At project commencement Exchange Information Requirements
shall be agreed, specifying the information deliverables, information exchange milestones and frequency.

3.2.1 Data structure

To facilitate standardised asset data delivery throughout the project lifecycle, the suppliers shall ensure that
all asset data is populated in a standalone tabular format (i.e. COBie register) which may in some instances
be derived from model attribution.
The following formats shall be accepted:
• A COBie register - as a subset of IFC (Industry Foundation Class), which is an open data schema, it
provides a recognised structure for asset information deliverables. The use of COBie (Construction
Operations Building information exchange) mitigates the time and potential inefficiency of
transferring data between platforms.
• A flat tabular format (excel or csv) per asset classification.
As defined in the KiwiRail Digital Engineering Information Protocol, tabular asset data takes
precedence over all other forms of attribution provided.
17 | © KiwiRail Digital Engineering Asset Information Requirements
3.2.2 Quality assurance
At the time of publishing AIR Version 1.0, KiwiRail is developing an asset data hand back toolset to improve
the quality of data received. The toolset shall validate asset data for the following quality metrics:
• Completeness – Is the required data present for a given exchange milestone (including metadata)?
• Uniqueness – Does the information have a unique identifier?
• Consistency – Is the number of assets and attribute data consistent?
It shall remain the responsibility of the supplier to ensure that all required attributes have been supplied,
and any missing attributes amended and resubmitted to KiwiRail for approval.

3.2.3 Exchange milestones

To support asset management planning, a first version of asset data including the assets, attributes, and
quantities should be provided at ‘Issued for Construction’ stage.
Complete asset data must be provided prior to asset handover.
Project specific information exchange milestones will be defined in the Exchange Information
Requirements.

18 | © KiwiRail Digital Engineering Asset Information Requirements

4 Asset documentation requirements
This section describes what asset documentation is required for asset management activities.

4.1 WHAT INFORMATION IS REQUIRED?

To support asset management activities a range of supporting documentation is required for each asset,
such as operating guides, commissioning reports, photos and warrantees. These documents are used
across KiwiRail by different teams for different purposes, and therefore must be discoverable and
accessible across the business.

4.1.0 Asset operations information

4.1.0.1 Operations and maintenance

Information related to an asset’s operation and maintenance requirements shall be provided to ensure
KiwiRail can effectively plan, schedule and undertake maintenance.
Information should include:
● Operational and Maintenance requirements and procedures (PPNOPs)
● Inspection and monitoring requirements
● Training manuals
● Technical maintenance requirements
● Schedule of special tools, plant or equipment required
● Indicative operation and maintenance programmes
● Decommissioning procedures
● Shutdown and outage procedures
● Maintenance required for specific components to maintain Warranties and/or Guarantees

4.1.0.2 Manufacturer information

Original Equipment Manufacturer Manuals (OEM) shall be provided.
Warranties and guarantees shall be provided. Warranty installation dates, periods, and expiry dates shall
also be provided as structured information as defined in the KiwiRail data dictionary.

4.1.0.3 Spares schedules

A spares schedule shall be provided for each asset type including:
● Illustrated parts list
● Supplier’s details
● Recommended spare parts
● Availability of spare parts e.g., lead times
● Ordering details e.g., serial numbers

4.1.1 Health, safety and risk

The following information related to health, safety and risk shall be provided:
● Residual Hazard Log - residual hazards that may create issues during future asset management activities. For
example, hazardous materials, undisturbed asbestos, ground investigation issues. The hazard should be attributed
to an asset classification or unique asset id.
● Safety Related Application Conditions (SRAC) – the conditions, configurations, and constraints that need to be
observed in order to operate or maintain the CRL assets safely and maintain the integrity of the safety argument.
SRAC’s should be attributed to an asset classification or unique asset id.
● Asset Risk Management Plans
● Safety in design reports
● Safety & system assurance certificates
● Failure Mode, Effects and Criticality Analysis

19 | © KiwiRail Digital Engineering Asset Information Requirements

● Safety Assurance Reports
● Incident and response management plans

4.1.2 Design and as-builts

The following information related to asset design and as-builts shall be provided:
● Whole-of life assessments
● Maintenance and operation concepts
● Competency register for design, construction and T&C personal
● Design Calculations
● Design Reports
● Standards Departure List (Design Period)
● Design Gate & Completion Certificate
● Asset Data Sheets

4.1.3 Construction, commissioning and testing

The following information related to asset construction, commissioning and testing shall be provided:
● Construction
– Construction Methodology/Method Statements
– Signed Inspection and Test Plan(s)
– Construction Monitoring Data
– Constructions Records
– Inspection Record Sheet(s)
– Snagging / defects lists check sheets.
● Testing & Commissioning Supporting Documentation
– Factory Acceptance test (FAT) certificate
– Component and Materials assurance test certificate (CAT, MAT)
– ASIT
– Commissioning Values
– Calibration Certificates
– Producer Statements
– Resource consents
● Property Information
– Property Title/Deed
– Deed of Grant
– Grant of Right
– Private Sidings Agreement
● Certificate of Train Running (CTR) and supporting completion test certificates

4.2 INFORMATION DELIVERY

4.2.1 Format
All documented asset information, such as a report or certificate, shall be delivered in the appropriate file
format defined in Digital Engineering Information Standard Part 2: Information Production.
Where documented information cannot be provided in the format specified in the Information Production
Standard (e.g. a manufacturer warranty), it may be provided as a machine readable PDF.
All documentation shall have metadata which maps the document to a unique asset identifier, asset
classification and/or discipline. The metadata required will be defined in the IDP and depend on the type
and expected usage of the information.

4.2.2 Exchange milestones

20 | © KiwiRail Digital Engineering Asset Information Requirements
Documented information exchange milestones shall be agreed in project specific Exchange Information
Requirements.
The KiwiRail Information Delivery Plan (IDP) template shall be completed by the lead delivery partner at
project commencement and agreed between KiwiRail. This will define when information is to be prepared,
by whom, and the Level of Information Need.

21 | © KiwiRail Digital Engineering Asset Information Requirements

5 Geometric information requirements
Geometric information includes 3D models, geospatial information, 2D drawings, point clouds, and LiDAR
outputs. Geometric information provides important context which, when combined with quality, structured
asset data, supports KiwiRail Asset Management activities.

5.1 3D MODELS
The creation of quality, information rich 3D models is a key enabler for KiwiRail’s Digital Engineering
aspirations. The KiwiRail Digital Engineering Information Standard Part 2: Information Production
defines the requirements to produce 3D Models during project delivery. The standard defines the Level of
Information Need, file submission formats, model naming convention and as-built model requirements
During asset delivery, geometric information shall be provided on a monthly basis as outlined in the project
contract and Exchange Information Requirements.
Asset data shall be embedded in the federated model, and where practical embedded in the native models
during the design stages. Tabular asset data (3.1) should be derived from the 3D graphical model. The
Kiwirail Digital Engineering Information Protocol defines precedence between tabular asset data and
asset data contained within a graphical model.

5.2 GEOSPATIAL INFORMATION

5.2.1 What information is required?

Geospatial information is required for many KiwiRail assets, with some requiring multiple geometry types.
For example, a fibre optic network has points for nodes, lines for cable, and polygons for cabinet assets.
Table 2 defines what asset types are required, including geometry and level of accuracy.
Table 2: GIS Information requirements

Asset Geometry type Accuracy level2

Track centreline Lines K5
Km posts Points K5
Tunnels Lines K5
Bridges and structures – including Lines, polygons K6
assets owned by other parties that
pass over the rail corridor
Underground services1 - including Points, lines, polygons K4
other party utilities that pass through
the rail corridor
Culverts Lines, points K5
Electrified track Lines K5
Level crossings Points K7
Signals and Indicators Points K5
Ducting Lines K4
Fibre optic network Points, lines, polygons K4
Track structures including turnouts Points K5
Stations Points K8

Contaminated land Polygons K6

1 This requirement is in addition to a subsurface utility model and will be reviewed in future AIR versions.

2 Accuracy levels defined in the KiwiRail Spatial Capture Framework

22 | © KiwiRail Digital Engineering Asset Information Requirements

All geospatial information shall contain a unique asset identifier (Section 3.1.3) in the layer attribution.
The required attribute information for each asset class is specified in Appendix E: GIS Attribution . KiwiRail
recognises the duplication by requesting asset data in layer attribution and is extending the data dictionary
to incorporate geospatial attribute data.
Each geospatial layer shall contain the following metadata:
Table 2: GIS Metadata Requirements

Metadata Description Format

Discipline_Originator_Description_DateUpdated
Layer Name KiwiRail GIS naming convention
e.g. DR_LKA_Drainage layer_220512

Description meaningful description of the layer Free text

Supplier Organisation Name of the organisation that provided the data Project specific list

Date Created The date the provided dataset was created DDMMYYYY

Date last updated The date the provided dataset was last modified DDMMYYYY

Name of the person/organisation that last updated

Last updated by Project specific list
the information

5.2.2 Information Delivery

Geospatial information shall be provided in the following format:
1. Esri file geodatabase
2. Coordinate system: NZTM/GD2000.
3. Vertical datum (including elevation attributes): NZVD2016
4. Geospatial information production shall follow the accuracy defined in the Spatial Capture
Framework.
Timing of project specific information exchange milestones for geospatial information will be defined in the
Exchange Information Requirements.

5.3 2D DRAWINGS
The Digital Engineering Information Standard Part 2: Information Production defines the requirements
to for 2D drawings during project delivery.
As specified in the Digital Engineering Information Protocol, drawings must be derived from a graphical
model.
As-built drawings are stored in Meridian – KiwiRail’s drawing management platform. Drawing numbers shall
follow the format Document Type – Line – Discipline – Drawing / Asset – Drawing number.
Table 3: 2D drawings naming convention

Component Description Format

Document Type Document Type e.g. DR drawing List - 2 letter alphanumeric

Line Related train line List – alphanumeric

Discipline Related discipline e.g. Signalling, SI List - 2 letter alphanumeric

23 | © KiwiRail Digital Engineering Asset Information Requirements

 Type of drawing or asset e.g. Layout,
Drawing / Asset Type List - 2 letter alphanumeric
component drawing

Drawing number Drawing number – provided by KR Numeric

The drawing requirements for Track, Civil and Signals 2D is detailed in Appendix F: Discipline 2D Drawing
Requirements.

5.4 POINT CLOUD & LIDAR

The Spatial Capture Framework defines the required accuracy and currency of spatial data. The Digital
Engineering Information Standard Part 2: Information Production defines the requirements to for Point
Cloud & LiDAR during project delivery.

24 | © KiwiRail Digital Engineering Asset Information Requirements

6 Appendices
6.1 APPENDIX A: TERMS AND DEFINITIONS
Term(s) Definitions ISO
19650
term

Appointed party Other consultants, sub-consultants to the lead appointed party, who is the provider of information
pertaining works, goods, or services.

Appointing party End client, Asset owner or similar. Receiver of information from appointed party pertaining to works,
goods or services.

Asset Item, thing, or entity that has potential or actual value to an organisation.

Asset information An Asset Information Model (AIM) is a model that compiles the data and information necessary to support
model (AIM) asset management, that is, it provides all the data and information related to, or required for the operation
of an asset. – Source NBS

Asset Life cycle Life of the asset from the definition of its requirements to the termination of its use, covering its
conception, development, operation, maintenance support and disposal.

Author/Owner The person responsible for the content in the information container.

Building information Use of a shared digital representation of a built asset to facilitate design, construction, and operation to
modelling (BIM) form a reliable basis for decisions

Note: BIM is a process for sharing structured information

Classification Information classifications allow information objects to be grouped for the purpose of common, agreed
controls. Examples of controls may include object permissions, workflows, naming etc.

Common data A system that manages the collaborative production, control and exchange of information based on a
environment (CDE) common standard and agreed access.

Content engine A content engine is a system designed to manage the production, control, and exchange of project
information. Content engines are chosen based on the content they will manage

Deliverable Information container contractually agreed to be supplied to the client. The product of engineering and
design efforts to be delivered to the client as digital files and / or printed.

Delivery team Lead appointed party and their appointed parties.

Multi-organizational team working on a part of the project under a lead appointed party

Design Intent Model A stage of the project information model which demonstrates the early co-ordination of multidisciplinary
design elements, including outline specifications and requirements.

Digital Engineering An agreed set of information to define the projects Digital Way of Working during the delivery phase.
Execution Plan
The digital work plan may also be referred to as a BIM Execution Plan, Digital Engineering Execution
(DEXP)
Plan, this may be dependent on industry or clients.

Document Information (meaningful data) and the medium on which it is contained. Container for persistent
information that can be managed and interchanged as a unit. This can represent snap shots from the
information model for a specific purpose.

This is a synonym to information container

Document code A unique code attached to an information container for management purposes. The document code may
also be referred to as the Information container code when applied to an information object.

Information For the purpose of this standard information is defined as geometric and non-geometric objects or set of
objects that forms part of the project information model and ultimately the asset information model.

Information A means of grouping information objects by a common purpose. For example, by Work breakdown
breakdown structure structure or plant area or facility.

25 | © KiwiRail Digital Engineering Asset Information Requirements

 Term(s) Definitions ISO
19650
term

Information container A named persistent set of information retrievable from within a file, system, or application storage
hierarchy.

An information container can refer to a specific information object or a set.

Information life cycle Information on a project goes through several stages starting with the requirements for information to the
final archiving of the information after project closure.

Information object A specific information container such as a document, geometrical model or piece of data which is
produced, received, or referenced during the delivery of the project.

This is a synonym to information container

Information set A set of information objects grouped for the purpose of information control. This control may include
reporting, quality assurance or workflow state change activities.

Information sets will be typically applied to define groups of information objects delivered as part of the
transmittal process. For example, an engineering work pack containing a number of information objects.

Issued An information object, or information package, that is distributed either internally or externally formally via
a transmittal. The act of issuing may be carried out for many reasons and is defined by status coding.

Typically, information is issued at defined workflow state changes such as Shared and Published.

Lead appointed party “Lead consultant”, EPC (Engineering, Procurement and Construction) or similar

Metadata Data that describes the information container stored in a common data environment (For example: project
number, title, life cycle state, revision, etc.).

Native Term used for the information objects original file format created by the authoring application. E.g. docx,
dwg, dgn, or rvt

Phase A point in time of an asset life cycle examples include opportunity, delivery and operational.

Project Unique process, consisting of a set of coordinated and controlled activities with start and finish dates,
undertaken to achieve an objective conforming to specific requirements, including the constraints of time,
cost, and resources.

For the purpose of this standard, a project is the full life cycle from initiation project hand back/closeout
according to the KiwiRail CPAD Manual.

Project Information Project Information Management is the application of management techniques and computer software to
Management collect project information, communicate it within and outside the organization, process it to enable
managers to make quicker and better decisions and ultimate disposition through archiving or destruction.

Project information A Project Information Model (PIM) is a model that compiles the data and information necessary to support
model (PIM) design and construction phase of an asset, that is, it provides all the data and information related to, or
required for the build of an asset.

Project team Appointing party and all the delivery teams

Published An information container is identified as ready for use outside the delivery organization, its actual use is
typically defined by status coding clearly defines its allowed use and may enable it to be used to support
different life cycle phases.

Typically, it will be formally issued to the employer or contractor at this life cycle phase and in a suitable
format.

Rendition A non-editable version of a native information container, typically a PDF or 3D review format such as
Autodesk’s Navisworks or Bentley’s imodel.

Retention period A time period applied to records to ensure retention of information to meet legal obligations and support
business continuity.

Retention periods are governed by the KiwiRail Information Management Policy, KRG-IS008-POL0.

26 | © KiwiRail Digital Engineering Asset Information Requirements

 Term(s) Definitions ISO
19650
term

Revision A formal label stored on an information container to formally identify it from previous copies of the
information container. Typically, revisions are incremented to reflect changes in life cycle states. Revisions
may be alpha or numeric characters or a combination of both.

Note: Revision numbers within the KiwiRail CDE are alphanumerical (e.g. P01) and are automatically
assigned based on review/approval workflows.

Shared Once development of a deliverable has reached a suitable point and has been suitably checked,
reviewed, verified, and approved, it may be shared outside of the immediate task team.

Typically, this is the point at which the design may be translated and made available for cross discipline
coordination. The information container may also be issued for external quality assurance review and/or
verification processes.

State A state represents the different areas of the Common data environment workflow through which
information objects transition.

The only defined states applied by this standard are Work in Progress, Shared, Published and Archived.

Status code A formal label stored on an information container to formally identify the allowed use of the information
container in a specific state in the workflow. (This term is contained in ISO 19650 and is also known as a
suitability code).

Supplier Supplier is used as an all-encompassing term for any party contracted to KiwiRail to undertake any form
of work, which could include; design (by a design consultancy) or construction (undertaken by a
contractor).

Task Information The management of information sets defined by individual activities or tasks. Each activity has a task
Management information delivery plan (TIDP) which described its information container, format, schedule etc.

Task information delivery plans are combined to form a master information delivery plan (MIDP).

Task team Individuals assembled to perform a specific task.

One or more task teams are appointed by the delivery team.

Small projects may define a single task team.

Version Versioning is a system-controlled copy of the information object to define an auditable history of change.

Virtual Construction The virtual construction model provides information describing the detailed design, and should be relied
Model upon for construction sequencing, methodologies, and other construction planning, before commencing
construction on site.

Work breakdown A means of breaking up the delivery of a project scope into packages, typically defined by a hierarchical
structure (WBS) coding system.

“deliverable oriented hierarchical decomposition of the work to be executed by the project team." –
PMBOK definition.

Work in progress The first state in a workflow at which effort is applied, ongoing development of a task or deliverable prior to
(WIP) review and approval for share outside the originating task team.

Typically work in progress is the only state where an information container can be edited.

Workflow The automation of a business process, in whole or part, during which information or tasks are passed from
one participant to another for action, according to a set of procedural rules, a series of states.

27 | © KiwiRail Digital Engineering Asset Information Requirements

6.2 APPENDIX B: DOCUMENT TYPE CODE LIST

Code Document Type Code Document Type

AM Agenda/Minutes MN Manual

AS Assumption MO Memorandum

AU Audit MP Management Plan

BQ Bill of Quantities NC Notice to Contractor

BR Brief NE Notice to Engineer

CA Calculations PC PCG Documents

CD Credit Summary PF PERF

CE Certificates PL Policy

CH Change Note/Request PP Pricing Package

CN Construction Notes PR Process or Procedure

CO Consents PS Presentation

CR Correspondence QA Quality Assurance

CT Contract RF Reference

DA Design Advice RG Register

DD Design Departure Request RP Report

DG Drawing RQ Requirements

DR Document Review Record RR Risk Register

DR Drawing Register SH Schedule (Programme)

DV Design Verification Record SK Sketch

ES Estimate SO Set Out

EV Evidence SP Specification

FM Form ST Standard

FN Financial TE Tender Document

FR Forecasts TM Template

GL Guideline TN Technical Note

IM Image/Photo/Video TP Task Plan

MA Media TR TOR

MD Model TS Transmittal

28 | © KiwiRail Digital Engineering Asset Information Requirements

6.3 APPENDIX C: DISCIPLINE CODE LIST

Code Discipline Code Discipline

AC Access Management IM Integrated Management Systems

AS Asset Management LD Landscaping

BC Business Case ME Mechanical Engineering

BM Benefits Management MP Mechanical, Electrical and Plumbing

CC Civil Engineering OL Overhead Line Equipment / Traction

CM Commercial Management PM Project Management/Controls

CN Contractor Management PR Procurement

CO Cost Management PS Project Management System

CP Construction Planning QS Quantity Surveying

CS Communications Systems RE Resource Management/Environmental Planning

CS Communications and Stakeholder RI Risk

CT Construction RM Rail Maintenance

DM Design Management RQ Requirements Management

DR Drainage RO Rail Operations

EH Electrical HV RS Rail Systems (general)

EL Electrical LV SA Safety and Systems Assurance

FE Fire Engineering SC Scheduling and Time control

FI Finance SM Stakeholder Management

GE General Engineering SI Signalling

GS GIS ST Structural

GT Geotechnical Engineering SV Survey and Mapping

GV Governance SU Sustainability

HF Human Factors TE Traffic Engineering

HR Human Resources TR Transport, Planning, and Integration

HS Health, Safety and Environment TU Tunnels

UT Utilities

29 | © KiwiRail Digital Engineering Asset Information Requirements

6.4 APPENDIX D: LINEAR REFERENCING REQUIREMENTS

6.4.1 Deriving Linear references

It is important to convert between linear reference and spatial coordinates accurately and consistently.
Where practical, it is preferred to derive linear references from as-built coordinates, but there may be
specific occasions where the linear reference is measured out on site – using a measuring wheel.
• Coordinates used to convert to linear references must be accurate as defined in the Spatial
Capture Framework.
• Conversion must be through approved KiwiRail processes. A web-based tool is expected to be
available for this purpose in late 2022. In the interim the conversion must be completed by the
KiwiRail Digital Engineering team.

6.4.2 Interim conversion requirements

For line features the start and end coordinates must be supplied separately. For polygon geometry the
KiwiRail track centreline should be used to derive start and end coordinates. Polygon or line geometry will
not be accepted.
A CSV of coordinates must be provided with the following schema for conversion:
• UniqueID
• X coordinate
• Y coordinate
The above headings should be included on the first row.
The coordinate system must be specified and be one of either:
• A local circuit (Eg Wellington Circuit)
• NZTM
• WGS84 (decimal degrees)
• Web mercator
A CSV will be returned containing UniqueID, Line, Side, Km, Offset

30 | © KiwiRail Digital Engineering Asset Information Requirements

6.5 APPENDIX E: GIS ATTRIBUTION

For each GIS dataset the following attribute schema shall be provided:
Dataset Geometry type Attribute Attribute type

Bridges line BRIDGE_NUM char(10)

Bridges line LINE_NAME char(50)

Bridges line TRACK char(15)

Bridges line FROM_KM char(10)

Bridges line TO_KM char(10)

Bridges line BRIDGE_NAM char(100)

Bridges line BRIDGE_TYP char(50)

Bridges line COMMENTS char(100)

Bridges line SEARCH char(25)

Bridges line LINE_NAME_ char(50)

Bridges line ID_Maximo char(255)

Culverts point KRSTARTOFFSETPROJ double

Culverts point MATERIAL char(30)

Culverts point FORM char(30)

Culverts point WIDTH double

Culverts point DEPTH double

Culverts point HEIGHT double

Culverts point DIAMETER double

Culverts point MULTI double

Culverts point ASSETNUM char(255)

Ducting line Depth double

Ducting line Status char(255)

Ducting line Diameter integer

Ducting line Material char(50)

Electrification line ID_Maximo double

Electrification line TrackInfo char(150)

Electrification line Location char(100)

Electrification line Reference char(50)

Electrification line Type char(50)

Electrification line Comments char(150)

FibreOptic line GRANTEE char(50)

FibreOptic line GRANT_NUMB char(20)

FibreOptic line RIGHT_NUM char(20)

FibreOptic line LINE_CODE char(20)

FibreOptic line KM_FROM char(20)

FibreOptic line KM_TO char(20)

FibreOptic line STATION char(50)

FibreOptic line DESCRIPTION char(150)

FibreOptic line DATE_ADDED date

FibreOptic line FILE char(30)

31 | © KiwiRail Digital Engineering Asset Information Requirements

 FibreOptic line PLAN_REF char(100)

FibreOptic line AS_BUILT char(10)

FibreOptic line SEARCH char(20)

FibreOptic line COMMENTS char(150)

FibreOptic point GRANTEE char(50)

FibreOptic point GRANT_NUMB char(20)

FibreOptic point RIGHT_NUM char(20)

FibreOptic point LINE_CODE char(20)

FibreOptic point KM_FROM char(20)

FibreOptic point KM_TO char(20)

FibreOptic point STATION char(50)

FibreOptic point DESCRIPTION char(150)

FibreOptic point DATE_ADDED date

FibreOptic point FILE char(30)

FibreOptic point PLAN_REF char(100)

FibreOptic point AS_BUILT char(10)

FibreOptic point SEARCH char(20)

FibreOptic point COMMENTS char(150)

FibreOptic polygon GRANTEE char(50)

FibreOptic polygon GRANT_NUMB char(20)

FibreOptic polygon RIGHT_NUM char(20)

FibreOptic polygon LINE_CODE char(20)

FibreOptic polygon KM_FROM char(20)

FibreOptic polygon KM_TO char(20)

FibreOptic polygon STATION char(50)

FibreOptic polygon DESCRIPTION char(150)

FibreOptic polygon DATE_ADDED date

FibreOptic polygon FILE char(30)

FibreOptic polygon PLAN_REF char(100)

FibreOptic polygon AS_BUILT char(10)

FibreOptic polygon SEARCH char(20)

FibreOptic polygon COMMENTS char(150)

Kmposts point KM float

Kmposts point LINE char(40)

Kmposts point KPOST char(50)

Kmposts point CONFIRMED smallint

Kmposts point LINECODE char(10)

Kmposts point LINE_CAP char(40)

Kmposts point NEEDSCHECK char(5)

Kmposts point SEARCH char(80)

Kmposts point LINE_ABBRV char(255)

LevelXing point alcamID char(6)

LevelXing point lineName char(50)

LevelXing point km double

32 | © KiwiRail Digital Engineering Asset Information Requirements

 LevelXing point type char(50)

LevelXing point control char(50)

LevelXing point ownership char(50)

LevelXing point assetID char(10)

LevelXing point deedOfGran char(10)

LevelXing point xingType char(25)

LevelXing point lon double

LevelXing point lat double

LevelXing point Status_Xin char(254)

LevelXing point ID_Maximo char(254)

LevelXing point GISComment char(254)

LevelXing point ValidateStatus char(50)

TrackCentreline line StartKm double

TrackCentreline line LINE char(40)

TrackCentreline line LINE_Type char(50)

TrackCentreline line LINE_ABBRV char(20)

Services line GRANT_NUMB char(20)

Services line CLASS char(50)

Services line DESCRIPTIO char(100)

Services line TLA char(150)

Services line COMMENTS char(150)

Services point GRANT_NUMB char(20)

Services point CLASS char(50)

Services point DESCRIPTIO char(100)

Services point TLA char(150)

Services point COMMENTS char(150)

Services polygon GRANT_NUMB char(20)

Services polygon CLASS char(50)

Services polygon DESCRIPTIO char(100)

Services polygon TLA char(150)

Services polygon COMMENTS char(150)

Signals point LineCode integer

Signals point KR_LINE char(8000)

Signals point ASSETNUM integer

Signals point DESCRIPTION char(8000)

Signals point STATUS char(8000)

Signals point EditedBy char(50)

Signals point EditedOn date

Signals point Xcoord double

Signals point Ycoord double

Signals point LABEL char(15)

StationsMajor point STATION char(20)

StationsMajor point KM double

StationsMajor point LINE_SECTI char(100)

33 | © KiwiRail Digital Engineering Asset Information Requirements

 Structures polygon ASSETID char(5)

Structures polygon STATIONCOD char(5)

Structures polygon STATION char(50)

Structures polygon ASSETTYPE char(20)

Structures polygon GISAREA double

Structures polygon VISIBLEAER smallint

Structures polygon COMMENTS char(100)

Structures polygon XCOORD double

Structures polygon YCOORD double

Structures polygon KM double

Structures polygon TRACKSIDE char(1)

Structures polygon DATASOURCE char(50)

Structures polygon ID0 char(10)

Structures polygon CNUMBER char(50)

Structures polygon COMPANYALL char(50)

Structures polygon STATUS char(15)

Structures polygon Toilet char(255)

TrackStructure point Location char(254)

TrackStructure point Reference char(50)

TrackStructure point Type char(50)

TrackStructure point Comments char(150)

TrackStructure point ID_Maximo char(255)

Tunnels line TUNNEL_NUM char(10)

Tunnels line LINE_NAME char(50)

Tunnels line FROM_KM char(10)

Tunnels line TO_KM char(10)

Tunnels line TUNNEL_NAM char(100)

Tunnels line SPATIAL_SO char(15)

Tunnels line COMMENTS char(100)

Tunnels line SEARCH char(25)

Tunnels line LINE_NAME_ char(50)

Tunnels line ID_Maximo char(255)

ContaminatedPolygon Polygon SITENAME char(50)

ContaminatedPolygon Polygon TYPE char(50)

ContaminatedPolygon Polygon COMMENTS char(50)

ContaminatedPolygon Polygon SITEAREA char(50)

ContaminatedPolygon Polygon CONTAMINATED char(50)

ContaminatedPolygon Polygon CONSULTANT char(50)

ContaminatedPolygon Polygon REPOARTLINK char(255)

ContaminatedPolygon Polygon MANAGEMENT char(50)

ContaminatedPolygon Polygon REPORTDATE date

ContaminatedPolygon Polygon PROCEDURE char(50)

ContaminatedPolygon Polygon EDITORNAME char(50)

34 | © KiwiRail Digital Engineering Asset Information Requirements

35 | © KiwiRail Digital Engineering Asset Information Requirements
6.6 APPENDIX F: DISCIPLINE 2D DRAWING REQUIREMENTS

For discipline specific drawing information requirements contact the KiwiRail Digital Engineering team.

36 | © KiwiRail Digital Engineering Asset Information Requirements