Digital Engineering Standard Part 1 Concepts and …...Digital Engineering Standard Part 1 – Concepts and principles DMS-ST-202 Standard – Applicable to Infrastructure and Place

Digital Engineering Standard Part 1 – Concepts and principles

DMS-ST-202

Standard – Applicable to Infrastructure and Place

Divisional Management System

Status: Final

Version: 3.0

Branch: Program Management Office

Section: Digital Engineering

Business unit:

Date of issue: September 2018

Review date: October 2019

Audience: Division wide

Asset classes: Heavy Rail; Light Rail; Multi Sites;

Systems; Fleets

Project delivery model: Not applicable

Project type: For all project types

Project lifecycle: Feasibility; Scoping; Definition;

Construction readiness; Implementation;

Finalisation; Not applicable

Process owner: Director


Program Management Office : Digital Engineering :


DMS-ST-202 DE STANDARD - PART 1_V3.0

DIVISIONAL MANAGEMENT SYSTEM DMS-ST-202

© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 2 of 50

Document History

Version Date of approval Doc. control no. Summary of change

1.0 September 2018 - Interim Approach Issue

1.1 - Minor updates

2.0 April 2019 - Project Data Building Blocks, minor updates

Separation of Part 1 and Part 2

3.0 October 2019 - Clarification on usage of ‘packages’ of work, visualisation added, survey updated, other minor updates







Preface

Transport for New South Wales (TfNSW) is developing the Digital Engineering (DE) Framework to facilitate time, cost and quality improvements to the way that projects are planned, designed, constructed, operated and maintained throughout their lifecycle. The current release of the DE Framework provides an Interim Approach, with continuous improvement towards best practice and a Transport cluster-wide fully implemented DE Framework.

DE processes included in the DE Framework provide TfNSW with an approach that creates digital information in an accessible format that will support and enhance stakeholder engagement, decision making, asset management, capability and capacity planning.

Implementing and adhering to this vision will enable individuals, who are responsible for the delivery and management of TfNSW’s assets, to make more informed decisions.

This document should be read in conjunction with all related DE Framework Interim Approach documentation. Any application of the DE Framework Interim Approach or any of its parts must be considered in a project-specific context. Adoption of the DE Framework should be undertaken in consultation with the DE Team ([email protected]) to ensure best appropriate practice.

Engagement with the Digital Engineering Team

The first point of contact for the project team, implementing this DES for a TfNSW project, is your project TfNSW DE Manager.

For general enquiries and assistance with application of this DES and associated guidelines, education, training, or planning and commencing a digital engineering project, please contact the Digital Engineering Team at [email protected].

The DE Framework embraces a culture of continuous improvement. Suggestions, comments and feedback are welcomed and encouraged.

https://www.transport.nsw.gov.au/digitalengineering

mailto:[email protected]

https://www.transport.nsw.gov.au/digitalengineering







Table of Contents

1. Introduction ................................................................................................................... 6

1.1. The Interim Approach ............................................................................................. 6

1.2. Purpose of this document ....................................................................................... 8

1.3. Structure of this document ...................................................................................... 8

1.4. Scope of this DES .................................................................................................. 8

1.5. Terms and definitions ............................................................................................. 9

1.6. References ............................................................................................................. 9

2. TfNSW Context ............................................................................................................ 11

2.1. TfNSW governance and control ............................................................................ 12

3. Digital Engineering ...................................................................................................... 14

3.1. Transport data and information asset management policy .................................... 14

3.2. Digital Engineering at TfNSW ............................................................................... 15

4. Information model concepts ....................................................................................... 17

4.1. Organisational information .................................................................................... 18

4.1.1. Organisational information requirements (OIR) ......................................... 18

4.1.2. Organisational information model (OIM) .................................................... 19

4.2. Asset information .................................................................................................. 20

4.2.1. Asset information requirements (AIR)........................................................ 20

4.2.2. Asset information model (AIM) .................................................................. 20

4.3. Project information ............................................................................................... 21

4.3.1. Project information requirements (PIR) ..................................................... 21

4.3.2. Project Information Model (PIM) ................................................................ 22

4.3.3. Project information model deliverables ...................................................... 23

4.4. Exchange information requirements ..................................................................... 24

5. Project Data Building Blocks ...................................................................................... 25

6. Project Data Schemas ................................................................................................. 27

7. Data classification and referencing ............................................................................ 29

7.1. Use of Uniclass 2015 ............................................................................................ 30

7.2. Location classification and referencing ................................................................. 30

7.3. Asset classification and referencing ...................................................................... 33

7.4. Discipline classification ......................................................................................... 35

7.4.1. Business discipline .................................................................................... 35

7.4.2. Technical discipline classification .............................................................. 36

7.5. Work Packages .................................................................................................... 36

8. Collaboration ............................................................................................................... 38

8.1. TfNSW and Contractor collaboration .................................................................... 38

8.2. Contractor team collaboration ............................................................................... 38

9. Common data environment concepts ........................................................................ 39

9.1. Approval states and suitability .............................................................................. 40

9.1.1. Approval state ........................................................................................... 40







Appendix A - DE Framework Documents ......................................................................... 41

Appendix B – Terms and definitions ................................................................................. 43







1. Introduction

1.1. The Interim Approach

This Digital Engineering Standard (DES) and supplementary templates and guidelines, form the Interim Approach that provides the tools and requirements to assist TfNSW projects seeking to implement DE post September 2018. These tools will continue to be developed over time, with incremental updates and new releases of the DE Framework documents provided.

The documents available as part of the DE Framework, are illustrated in Figure 1. Appendix A provides further details.

The DE Framework documents include:

1. The TfNSW Digital Engineering Standard and supporting guides:

a. The TfNSW DE project set-up, commercial and procurement guidelines and project management tools are for use by TfNSW staff implementing DE on a project and provide guidance, contract templates and DE tools and templates.

b. The Supporting Technical Guides provide practitioner-level guidance on the implementation of the specific requirements of the DES, based on DE discipline, and provide worked examples.

2. Tender Documents provide guidance on the adaptation of standard TfNSW contract templates for use on DE enabled projects. These templates reference the DES, with project-specific DE requirements included in the DE Execution Plan (DEXP) template. The completed DE contract documentation, Project DEXP template and DES are then provided to the Contractor.

3. The Contractor Documents, specific to DE. This includes the project specific DEXP (Project DEXP), completed and approved for implementation by TfNSW.

Note, for complex projects where the work is to be completed as separate stages or by various subcontractors, multiple project DEXPs may be required. Where multiple plans are required, these must be aligned with a lead DEXP.







Figure 1: DE Framework Document Hierarchy

TfN

SW

Do

cum

en

tsT

end

er

Do

cum

ents

Pro

ject

Do

cum

en

ts

Intern al TfNSW Do cument

Co ntrac tor Do cument

TfNSW Guides TfNSW Template

TfNSW DE Procurement and

Project Management Guides

Supporting Technical Guides

Data and Information Asset Management

PolicyCP17005

Project DEXP Template

Project Deed TfNSW Standard

RequirementsProject Services/

Works Brief

Project SpecificDEXP

Digital Engineering

Standard

Standard(mandatory)

Policy

Project Data Building Blocks

Project Data Schemas







1.2. Purpose of this document

This DES is the lead document in the DE Framework for the Contractor, providing minimum requirements for implementation of DE. It details how the Data & Information Asset Management Policy is to be implemented through the application of the DE Framework.

This DES describes the language and approach to be adopted when implementing DE for TfNSW projects.

Specifically, this DES provides requirements and guidance on:

• The structure of the DE Framework, including DE’s influence on the achievement of organisational and asset management objectives

• The structure and information workflow within a project team’s Common Data Environment (CDE)

• The requirements for Project Data Building Blocks (PDBB) and Project Data Schemas (PDS), which is a common language and structure for all project information and data

• The implementation of 3D modelling and the expectations of how project teams should integrate 3D into project delivery

1.3. Structure of this document

This document is provided in two parts:

1. Part 1 (this document) – TfNSW Digital Engineering Standard, Concepts and Principles (DMS-ST-202) - An overview of the TfNSW operating environment and DE concepts.

2. Part 2 – TfNSW Digital Engineering Standard, Requirements (DMS-ST-207) - The management requirements and technical outputs (deliverables/submissions) that are required during the delivery of a TfNSW DE-enabled project.

This document is to be read in conjunction with the TfNSW Configuration Management Plan (T MU AM 04001 PL) and relevant Agency configuration management plans.

1.4. Scope of this DES

This DES is applicable for Infrastructure & Place (IP) staff and Contractors delivering TfNSW DE-enabled projects during the Plan-Acquire phases (ie planning, design and construction). The Demand/Need, Operate/Maintain and Dispose phases of the asset lifecycle are not currently within the scope of the DE Framework. Refer to Figure 2.







Current scope of DE

Figure 2: The current application of DE within the asset lifecycle

The scope of the DE Framework is limited to the implementation of Computer Aided Drafting (CAD), Building Information Modelling (BIM) and document and information management. DE requirements for digital survey, systems engineering, scheduling, cost management, visualisation and asset data are provided to enable digital delivery of existing TfNSW requirements.

When implementing DE for TfNSW projects, this DES should be read in conjunction with all related requirements set out in the contract documents.

DE activities currently excluded from the scope of the DE Framework are:

• BIM for operation and maintenance

• Advanced building materials

• Pre-fabrication and modular construction

• 3D printing and additive manufacturing

• Autonomous construction

• Augmented reality

• Big data and predictive analysis

• Wireless monitoring and connected equipment

• Cloud and real time collaboration

It is expected these items will be covered in later releases of the DE Framework.

1.5. Terms and definitions

The terms and abbreviations used in this document have the meaning/definitions provided in Appendix B, DMS-ST-123 Terms and Definitions.

1.6. References

This DES makes reference to various TfNSW and industry standards and guidelines. Sources include:

• TfNSW Asset Standard Authority (ASA)







• IP standards and procedures

• ISO, Publicly Available Specifications (PAS) and industry standards and guidelines.

A list of references and relevant standards and guidelines is provided in DMS-ST-207 Digital Engineering Standard, Part2 - Requirements.







2. TfNSW Context

TfNSW manages a complex multi-modal portfolio of assets, including:

• fleet (buses, ferries and trains)

• discrete or non-linear infrastructure (interchanges, stations, stops, buildings, stabling yards, substations, wharves)

• linear infrastructure (roads, railways, utilities and services).

IP is the asset custodian on behalf of TfNSW and responsible for the planning and delivery of major procurements/projects for several classes of asset. Each Operating Agency within the Transport Cluster (refer to Figure 3) has specific responsibilities, primarily focused on operation and maintenance, but also including major and some minor projects. There are also discrete delivery offices, such as Sydney Metro.

Figure 3: The Transport Cluster Operating Model

TfNSW was established in 2011 by bringing together a number of previous government departments and agencies to form the Transport Cluster. Through this evolution, IP and each of the Operating Agencies have historically customised local asset standards, with varying data structures and information exchange requirements. This creates significant complexity







in project management, design and asset management, particularly for multi-modal projects with multiple asset custodians.

In addition to the interfaces created by the duplication and variety of standards, there are a broad range of commercial delivery strategies employed to design and build infrastructure projects such as: internal and outsourced delivery, Public Private Partnerships (PPP), Alliances, Managing Contractors, Design Only, Design and Construct (D&C), and Construct Only. These various commercial delivery strategies often create the need to exchange information between multiple interfacing Contractors, creating further complexity for information management and collaboration.

The vision of the TfNSW DE Framework is to minimise this complexity, by introducing consistent data structures and open data exchange protocols, while remaining software and technology agnostic. Using consistent methods enables information to be easily exchanged between TfNSW and contractors while allowing contractors to continue using their own Common Data Environment (CDE).

The implementation of DE will ensure data is structured so that it can be easily developed, shared and maintained throughout the asset lifecycle.

This Interim Approach DES has been written to support the IP division, which is responsible for providing integrated end-to-end planning, development, delivery and operations of transport services. However, the principles of the DE Framework and this DES are designed to be practical and scalable for all TfNSW divisions and Operating Agencies, with the intent for the DE Framework to be integrated across the Transport Cluster in the coming years.

2.1. TfNSW governance and control

TfNSW provides two project assurance gateway frameworks that must be complied with by all projects delivered for TfNSW:

1. Investment Assurance Gates (IAG) – ensuring value for money

2. Configuration Management Gates (CMG) – assuring the physical asset

The DE Framework is aligned with the IAG and CMG, associating the requirements for the digital asset assurance with the physical asset assurance. The timing of the IAG and CMG during the asset lifecycle are shown in Figure 4.

Figure 4: Governance and Control Gates

ConfigurationManagementGates

InvestmentAssuranceGates

Demand/Need

IAG 0

Project

justification IAG 1Strategic assessment

IAG 2Business case

CMG 1

Need

Demand

End of asset

lifecycle

CMG 3

Plan Aquire

Build

IAG 5Pre-commissioning

HandoverIAG 3 & 4Pre-tender & tender evaluation

IAG 6Maintenance plan

Accept

Operate/Maintain

CMG 6

Evolve

Operate

Maintain

Dispose

Dispose

CMG 0

SpecifyConcept DesignProcurement

CMG 4

Integrate

CMG 5CMG 2







Table 1 provides an overview of the function and activities at and between configuration management gates.

Table 1: Standard configuration management gates for full asset life cycle (source: T MU AM 04001 PL TfNSW Configuration Management Plan)

Lifecycle Phase

Activities Governing CMG

CMG Evidence

Demand / need

Transport issues, network need and strategic alignment

CMG 0 Business requirements specification Initial safety change assessment Preliminary assurance and governance plan

Plan Solution identified and requirements defined

CMG 1 System requirement specification Impact assessment of change Assurance and governance plan

Acquire Preliminary design CMG 2 Assurance against assurance and governance plan

Detailed or critical design CMG 3 Assurance against assurance and governance plan approved for construct design

Manufacture, construct or install

CMG 4 Assurance against assurance and governance plan Evidence ins

Inspection and test CMG 5 Assurance against assurance and governance plan Operational and maintenance readiness addressed Configuration information assured and delivered Residual safety risks identified

Operate / Maintain

Operations and maintenance CMG 6 Annual asset maintenance plan Evidence of risk based assessment in developing maintenance plan

Dispose Decommission and disposal - Evidence supporting new configuration change

For further information regarding the governance and control gates, refer to:

• the TfNSW Configuration Management Plan (T MU 04001 PL)

• iNSW Project Assurance http://www.infrastructure.nsw.gov.au/project-assurance

• IP DMS Integrated Assurance Framework







3. Digital Engineering

3.1. Transport data and information asset management policy

TfNSW is committed to implementing best practice data and information management within a digital environment, in line with the Transport Data and Information Asset Management Policy (CP17005). As stated in this policy, Transport supports the adoption of the following principles:

• Single source – Ensuring service and asset data is accurate, current, reliable and not duplicated

• Collaboration – Increasing access and sharing, reducing latency for improved decision making

• Automation – Reducing or eliminating manual work associated with creating or sharing data

• Interoperability – Reducing or eliminating double handling of data between systems

• Mobility – Enabling access to and input of data from multiple locations including the field

• Visualisation – Incorporating methods to develop, coordinate and check service and asset data spatially

• Data governance – Comply with information management policies, including open data, data information custodianship and information security

The application of these principles in a project context (refer to Figure 5) has led to TfNSW defining a common language and approach for contractors to use when developing and managing digital information which TfNSW refers to as DE.

Figure 5: Examples of DE in use in TfNSW projects







3.2. Digital Engineering at TfNSW

DE is a collaborative way of working, using digital processes that enable more productive methods of planning, constructing, operating and maintaining TfNSW’s assets.

Together, these standardised ways of working collaboratively utilising digital enablers, comprise the TfNSW DE Framework (refer to Figure 6). The DE Framework links to, or is integrated with, many of TfNSW’s existing management frameworks, providing a cluster-wide approach to DE.

Figure 6: The Digital Engineering Framework

When the DE Framework is implemented, it will lead to time, cost and quality efficiencies for TfNSW and its Contractors throughout the project lifecycle. For information on possible uses and benefits of DE, refer to Table 2.

Table 2: DE Uses and benefits

DE Use Description and Benefit

Design Integrate the design of architectural, structural and Mechanical, Electrical & Plumbing elements of the infrastructure/asset, including the surrounding areas, assisting with systems engineering.

Coordination The federation of the different design BIM models at key project milestones (e.g. prior to a design Submission) allows project teams to discover conflicts or inconsistencies before construction starts.

2D Drawings 2D drawings can be extracted from the model and the drawings will be up to date, coherent and clash detected.







DE Use Description and Benefit

Visualisation and communication

BIM models (3D) can be used to communicate design solutions to designers and other stakeholders. For example, it is possible to walk through the model, create animations, and see 3D images or visualisations.

Decision support DE provides a platform to investigate different alternatives by comparing various properties such as functionality, scenarios and costs. This can assist with, for example, options analysis and can support investment decision making.

Quality assurance DE enabled design reviews enables discovery and problem solving in the design phase instead of during construction.

In future, TfNSW will be able to validate the design with a rule-based validation programme to determine whether the requirements have been met.

Models can be used for fire safety reviews, Building Code of Australia reviews and/or to check accessibility for maintenance crews.

Quantity take-off Quantities can be extracted from BIM models for tendering, as well as for purchases during the construction phase.

Time simulation The BIM model can be linked to a schedule and generate time simulations to assist with optimising construction sequencing.

Cost estimating The BIM model can be linked to provide the evolution of costs during the project delivery process for automated forecasting and earned value calculation.

Analysis DE can help stakeholders to simulate the lifecycle performance of the asset, including structural, MEP, energy, acoustical and lighting analysis.

Constructability BIM models can be used for safety planning, eg to analyse construction site layout, including understanding the impacts and interactions with the surrounding areas.







4. Information model concepts

The structure of the DE Framework is based on the information principles of ISO 19650 Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) -- Information management using building information modelling.

An Information Model, as defined by ISO 19650, is a set of structured or unstructured information. This includes geometric data (including 2D drawings and BIM models), non-geometric data (including spreadsheets and databases) and any other information (for example, email correspondence and documents) required to deliver and manage an asset throughout its lifecycle.

Figure 7 illustrates TfNSW’s conceptual information model. It extends the ISO 19650 model by introducing the concept of Organisational Information Model (OIM), and shows how the Project Data Building Blocks (PDBB) and Project Data Schemas (PDS) realise the Project Information Requirements (PIR) and Exchange Information Requirements (EIR) respectively. The PDBB act as the project source of truth for key project information which in turn enables the PDS thus ensuring data is consistent and standardised.

In general, information requirements structure and standardise all data that comprises the Information Model. The data and information that is to be provided throughout the asset lifecycle (Information Requirements), are determined by TfNSW’s objectives at each stage. The data and information is used to assess performance against the TfNSW objectives and to assist in lifecycle decision-making.

Organisational

Information Model

(OIM)

ass

ure

s

Project Data

Building Blocks

(PDBB)

realizes

Project Data

Schemas (PDS)

implementsISO 19650

TfNSW DE Framework

enables

Figure 7: The information model (adapted from ISO 19650)







The project information required to be generated by a specific Contractor for contribution to a PIM is defined in the Exchange Information Requirements (EIR), which are collectively specified in the TfNSW DE Standard, the Contract, DEXP template and PDS.

The project information created during project planning and delivery (the Demand/Need, Plan and Acquire phases) by TfNSW and all Contractors forms the Project Information Model (PIM).

The information handed over to the operator and maintainer from the PIM, and the additional information generated during the operations and maintenance phase forms the Asset Information Model (AIM).

The individual project Asset Information Models contribute to the overall Organisational Information Model (OIM). The OIM enables assessment of performance against the Organisational Information Requirements (OIR).

These components are detailed further in the below sections.

Organisational Information Requirements

Project Information Requirements Asset Information Requirements

Asset Information ModelProject Information Model

Organisational Information Model

Current scope of DE

Figure 8: Information Requirements and Information Model integration

4.1. Organisational information

4.1.1. Organisational information requirements (OIR)

TfNSW’s information requirements are specified in the strategy documents and frameworks developed and documented to guide business objectives and outcomes. Overarching OIR are defined in TfNSW’s Future Transport Outcomes (Future Transport Strategy 2056, https://future.transport.nsw.gov.au/). These outcomes drive key information requirements throughout the lifecycle and determine the resulting information models. The integration of information requirements and information models across the asset lifecycle is provided in Figure 8.

https://future.transport.nsw.gov.au/







The TfNSW Future Transport Strategy is focused on six key outcomes for the future of mobility in the state, which together aim to positively impact the economy, communities and environment of NSW. Achieving these outcomes has underpinned every planning decision in the development of the Transport Strategy and drives TfNSW’s asset management planning.

To achieve and measure the success of the six strategic outcomes (refer to Figure 9), specific information is required from the business. It is this required information that, primarily, forms TfNSW’s OIR. OIR are also dictated by wider NSW Government policies and frameworks, industry compliance requirements and TfNSW group policies.

Figure 9: TfNSW’s six key outcomes (TfNSW Future Transport Strategy)

4.1.2. Organisational information model (OIM)

The OIM is an introduced concept that is not discussed in PAS 1192-3:2014. The OIM includes information from all project and asset information models (inter-Agency and inter-modal), as well as the wider business, to provide an integrated organisation-wide information data model. Example information outputs generated from the OIM as a result of the OIR include:

1. Monthly and annual reporting

2. Business and strategic plans

3. Health checks







4. Forecasts and projections

5. Network and project performance

6. Passenger travel and satisfaction reports

4.2. Asset information

4.2.1. Asset information requirements (AIR)

The AIR are generally specified by the owner’s and/or custodian’s asset management objectives, which in turn are derived from the OIR, and detail all information and data that is needed to manage the asset effectively.

AIR specific to the Operations and Maintenance (O&M) of the asset and generated as a result of O&M activities, are defined in the O&M contract. The contract specifies the mechanism, format and frequency that the O&M information needs to be provided to support business functions during service and to aid in effective asset management.

A subset of information required by the AIR is generated during the delivery of a project. Where this is required, these AIR are specified as part of the project PIR, to ensure that the asset data and information required is captured during project delivery.

This DES incorporates AIR that are to be generated during project delivery (the plan and acquire phases), and explains the requirements for the asset information to be produced up until asset handover, making reference to other TfNSW standards where applicable.

4.2.2. Asset information model (AIM)

The Asset Information Model (AIM) is the name given to all asset information deliverables produced in response to the AIR. The AIM is generated for use in the O&M phase. Information contributing to the AIM may initially be generated during the project delivery phases and handed over from the project team to the O&M party(ies) as part of a formal acceptance procedure. This information is then built upon by the O&M team as a result of evidence generated during operation and maintenance activities (refer to Figure 10).

Asset information generated by the O&M as a result of post-asset handover activities, including asset performance and condition data, is outside of scope for the DES at this time.

This revision of the DES specifically addresses the minimum requirements for asset information that must be generated as part of the DE process during delivery for asset handover, including:

1. Handover Asset Register

2. Requirements Traceability Verification Matrix (RTVM)

3. Capital expenditure for capitalisation

4. Completed Inspection and Test Plan (ITP)

5. O&M manuals

6. As-Built drawings and 3D models







It is critical to the success of DE that the AIM information is managed as a ‘digital asset’ both during delivery and throughout O&M.

Asset Information ModelProject Information Model

Archived PIM information

Asset information

received from the project

Asset information

generated during O&M

Project management information

Asset information

Current scope of DE

Figure 10: Development of the AIM

4.3. Project information

4.3.1. Project information requirements (PIR)

As outlined in Figure 10, the PIR are comprised of two parts:

1. Project management information requirements – the information that is required to undertake project management, governance and assurance functions, but archived at asset handover.

2. Project asset information requirements – information about the asset and asset systems that is required for configuration management, engineering assurance, and to demonstrate business and system requirements traceability/compliance. This information is built-up over the life of the asset. A defined sub-set of data is transferred from the PIM at asset handover into the AIM.

The PIR for TfNSW - IP projects are specified in this DES and defined in the project contract, including the TfNSW Standard Requirements and Project Services/Works Brief (refer to Figure 11).







Standard (mandatory) Project DEXP

Template

Project Deed TfNSW Standard

RequirementsProject Services/

Works Brief

Digital Engineering Standard

Data and Information Asset Management

PolicyCP17005

Figure 11: PIR defined within contract and standard documents

4.3.2. Project Information Model (PIM)

The Project Information Model (PIM) contains all documentation, non-geometric (data) and geometric information (engineering drawings and models) used and produced during the planning, design and construction phases of the project. The systems used to structure and store this information are referred to collectively as the Common Data Environment (CDE), refer to Section 9 for further information regarding the CDE.

The information contained within the PIM includes all deliverables identified in contract documentation including asset owners’, Standards and any other information relied on or used by the Contractor for the development and delivery of the project.

All project and asset information remains within the PIM until the TfNSW project transitions into the O&M phase at asset handover. On handover of the physical asset and appropriate associated information, the PIM relevant to O&M is transferred and further developed by the Operator and Maintainer during the O&M phase. Those sections of the PIM that are not required for the O&M phase are archived for future reference.

Successful handover of information from the project delivery-phase PIM to the AIM, requires that there is an alignment/mapping of asset information metadata in the asset register to project information metadata, particularly delivery work package location and asset location. This concept and the requirements for data formats are provided in DMS-ST-207 Digital Engineering Standard, Part2 - Requirements.







4.3.3. Project information model deliverables

As explained previously the PIM consists of two parts, the project management information that is archived at the end of the project, and the project asset information that is handed over to O&M.

Examples of the types of project management information produced include:

• All design engineering information including CAD, BIM (3D models) and GIS information

• Temporary works information

• Time and scheduling information

• Cost management data

• Registers such as: risk registers, issue registers, interface registers

• Safety management information such as Safe Work Method Statements (SWMS), hazards

• Environmental information such as key constraints and conditions of approval

• Project management data

• All other relevant project information

Examples of project asset information that is transferred to the AIM at asset hand over includes:

• Handover Asset Register

• All As-Built engineering information including CAD, BIM (3D models) and GIS information

• Quality assurance information such as Inspection and Test Plan (ITP) and manuals

• Warranties

• Residual risks and hazards

• Actual delivery costs by asset type and location

• Other relevant asset management information for operations and maintenance

Refer to T MU AM 02001 ST Asset Information and Register Requirements and the project contract for project-specific asset handover information requirements.

The success of DE on a project is largely dependent on how disciplined the team is at managing change within the PIM, and ensuring its data is structured consistently and in accordance with the information requirements.







4.4. Exchange information requirements

The Exchange Information Requirements specify the production, management and characteristic requirements of information to be submitted under a particular contract. These requirements detail deliverables and standardise information characteristics such as:

Source

File format

File size

Data structure

Data security

In order to integrate with the TfNSW commercial framework, the Exchange Information Requirements provided to a Contractor are provided across several key Contract documents. These include the Services/Works brief, Management Requirements, the Digital Engineering Standard Part 2 – Requirements (DMS-ST-207), the project specific DEXP Template (based on DMS-FT-532) and associated Project Data Schemas (PDS). Refer to sections 5 and 6.







5. Project Data Building Blocks

Requirements for structured data exist so that the data and information produced within and between projects can be federated, interrogated, verified, analysed and reused.

The Project Data Building Blocks (PDBB) is a collective name for the structured data being utilised by the project team in the creation of data and information deliverables.

Figure 12: The Project Data Building Blocks (PDBB)

The PDBB are made up of:

• Standard TfNSW Building Blocks – Standard TfNSW master data that is static and common to all projects, and

• Project Specific Building Blocks – Project created data that follows specified data structures that leverage standard TfNSW master data. A central part of this data includes asset-related information which follows a classification and referencing approach outlined in section 7.

The TfNSW client project team uses the PDBB template (DMS-FT-548) to define the Project Specific Building blocks. Figure 13 illustrates the key data & relationships that the PDDB supports.

Once defined, the PDBB are utilised by multiple teams for deliverables across the project, with requirements for usage in the creation of individual DE deliverables specified in the Project Data Schema (PDS) (refer to section 6).

Due to the critical nature of the PDBB and their role in the success of DE within the project and across TfNSW, TfNSW mandate that for Digital Engineering projects:

• The TfNSW project team or delegated representative will create manage and maintain the PDBB (refer to DMS-FT-548 Project Data Building Blocks Template) during the life of the project.

• Alignment of Project Data Schemas (PDS) with the PDBB is to be maintained throughout the life of the project.

• Changes to the PDBB are to be confirmed in collaboration with TfNSW.

The project procedures for control and governance of the PDBB and change requests is to be confirmed in the Project DEXP, utilising DMS-FT-374 DE Code Request Form.

Standard TfNSW Building Blocks Project Specific Building Blocks







Figure 13 PDBB - Key data and relationships

Products (Pr)

Elements/Functions (EF)

Systems (Ss)

Business Disciplines

Technical Disciplines

Complexes (Co)

Entities (En)Spaces/Locations

(SL)

Design PackagesConstruction

PackagesCommissioning

PackagesSupply Packages

Organisations

Document TypeProject MilestoneSecurity

Classifications

Document Suitability Status

Codes

Project Phases & Stages

Other

Contract TypesWork Packages define

the asset-related scope of contracts

Programs group

Projects

Project are delivered

via Contracts

Systems are

grouped by TDs

Locations group assets

Work packages group assets

Work Package Types

Work Package Groups

Work Packages

are grouped by

Work Package

Types







6. Project Data Schemas

The Project Data Schemas (PDS) provide the structure and data rules for the exchange of information between project participants and across project phases, incorporating appropriate data from the PDBB. Each DE discipline (for the Interim Approach these are, systems engineering, survey, CAD, BIM, Visualisation, GIS, time, cost, asset data) has its own requirements for information and as such there is a specific PDS for each DE discipline.

It is critical that any common information represented within the various schemas is in the same way (ie: same code and description).

Changes to data standardisation and configuration, defined by the PDS, have wide-reaching implications: the project data does not exist in isolation but is part of the wider project, Agency and Cluster PIM, AIM and OIM. For this reason, any proposed changes to the PDS must be approved by TfNSW such that the accepted changes can be incorporated into the PDBB and cascaded to all interfacing datasets and systems.

The relationships between the Project Data Building Blocks, incorporating classification, and the PDS are illustrated in Figure 14. The PDBB are a critical component of the PDS, allowing the linking of data across and between datasets.

Figure 14: The PDBB – PDS relationship







TfNSW DE Framework recognises the need for multiple schemas to cater for each type of information and data created by the DE disciplines. These schemas vary based on current technology limitations and may be modified to enable PDBB to be applied in a practical and user-friendly way.

PDS will be populated with project-specific data by TfNSW and provided to the Contractor as appendices in the DEXP template. The Contractor will be provided with the flexibility to request changes the PDS proposed by TfNSW.

The Contractor is also free to add additional granularity below the coding structures provided by TfNSW, however the new codes must always roll-up to the standardised structures provided by TfNSW to enable PIM and AIM requirements.







7. Data classification and referencing

For DE projects, data is to be classified and referenced (named) appropriately such that it can be identified, managed, federated, stored, analysed and interpreted correctly, both within a project context, as well as an organisational context. Identified classifications and defined references for a project are a fundamental component of the Project Data Building Blocks (PDBB). Classifications and references within the PDBB are maintained as a central point of reference, to be applied appropriately to any data or information created during the project.

Specific classification and referencing is to be applied to Discipline, Asset and Project Location, with these classification relationships illustrated in Figure 15.

Discipline(Business or Technical)

Asset(System + Type)

Location(Project Location)

Figure 15: DE Classifications

The different classifications provide analysis of information to the project and TfNSW:

• Location: enables grouping of data, activities or assets by location.

• Asset: enables grouping of data, activities or assets by type and/or system.

• Discipline: enables assignment of responsibility or grouping for an activity, asset or document by the business or technical discipline.

Table 3 provides a summary of classification types and their corresponding standard.

Table 3: Classification standards

Ref Classification Sub-classification Standard

1 Location Project Uniclass 2015, Complexes (Co), Entities (En), Spaces/Locations (SL)

2 Asset

Type Uniclass 2015, Elements/Functions (EF) or Products (Pr)

3 System Uniclass 2015, Systems (Ss)

4 Discipline

Business TfNSW defined

5 Technical TfNSW defined







The different classifications are illustrated in Figure 16.

Asset ClassificationLocation Classification Discipline Classification

Products (Pr)


Systems (Ss)

Complexes (Co)

Entities (En)

Business Discipline

Technical DisciplineSpaces/Locations

(SL)

Figure 16: Classification relationships

These classifications and associated references are further described in the following sections.

7.1. Use of Uniclass 2015

TfNSW has chosen to adopt Uniclass 2015 (developed by NBS) for classification of assets and locations during the Plan-Acquire phases. The choice to adopt Uniclass 2015 follows comprehensive research and analysis of available classification systems, industry-wide, against ISO 12006.2:2015.

TfNSW is engaging in ongoing work with NBS to continually improve this standard.

For more information regarding TfNSW’s adoption of Uniclass 2015, refer to DMS-SD-124 Application of Uniclass 2015 for Transport.

Refer to https://www.thenbs.com/ for further information in relation to Uniclass 2015.

The ASA and the DE Team continue to collaborate to improve the use of classification for best appropriate practice and to facilitate TfNSW business functions.

For assistance with the application of Uniclass 2015 in your project, seek guidance from your DE Manager or contact the DE Team at [email protected].

7.2. Location classification and referencing

Location classifications and referencing are used to indicate where an asset is in relation to other assets (as opposed to location in space or geo-reference) and/or where activities take place.

Project Location is used during the Plan-Acquire phase, for grouping assets into practical project delivery areas or work packages.

For the purposes of DE, an asset is located within the project (i.e. has a Project Location) if its midpoint is within the project boundaries.

https://www.thenbs.com/

mailto:[email protected]







The TfNSW DE Framework requires the use of the Uniclass 2015 Complexes (Co), Entities (En) and Spaces/Locations (SL) classification tables to describe the various project location containers/groups of assets within common locations during project delivery. The possible combinations of these classifications are illustrated in Figure 17.

Location Classification

Complexes (Co)

Complexes (Co) Entities (En)

Complexes (Co)Spaces/Locations

(SL)

Complexes (Co) Entities (En)Spaces/Locations

(SL)

Figure 17: Possible project location classification relationships

All locations within the Transport network as a minimum must also be associated with a parent network code (for example, Uniclass 2015 Co: Co_80_35_75 Road networks, Co_80_50_35 Heavy rail complexes, Co_80_50_45 Light rail complexes) to differentiate the mode.

It is noted that intricate asset Entities (En) may have child Entities (En) within them. For example, a Station entity can have within it a shop unit entity, platform entities and toilet building entities. Likewise Spaces (SL) can have child Spaces (SL), such as a level can have rooms within it.

As a project progresses and the project is specified in more detail, the specification of locations also becomes more defined. The project location classification is usually specified much earlier in the project lifecycle than assets.

Often, the Complex (Co) and Entity (En) is known in the earliest demand/need or planning phases. The Entity would then be further specified into Spaces (SL) during, for example, concept or preliminary design. This is reflected in the application of the project location classification codes in the example provided in Table 4.







Table 4: Project Location classification and referencing example

CMG Reference and classification example

CMG0

CMG1

CMG2

CMG3, CMG4 and CMG5







The location classifications and references defined for a project are centrally managed as Project Data Building Blocks (PDBB). Currently, these intricate asset location hierarchies must be managed outside of many model authoring tools. The DE Framework provides a template for the management of the PDBB, refer to DMS-FT-548 Project Data Building Blocks Template.

Further guidance and examples of the application of classification are provided in DMS-SD-124 Application of Uniclass 2015 for Transport.

7.3. Asset classification and referencing

During the Design/Construct phases, asset types are classified using the Uniclass 2015 Elements/Functions codes (EF) or Products codes (Pr). Groups of assets that work together to deliver a function are linked together by a System code (Ss). The possible combinations are illustrated in Figure 18.

Asset Classification


Systems (Ss)Elements/

Functions (EF)

Products (Pr)Systems (Ss)Elements/

Functions (EF)

Systems (Ss)

Products (Pr)Systems (Ss)

Figure 18: Possible asset classification relationships

As for location classification, as a project progresses and the asset is specified in more detail, the classification relevant to the asset elements, systems, and products becomes more defined (refer to Figure 19, NB Level of Definition (LOD) is defined in DMS-ST-207 Digital Engineering Standard, Part2 - Requirements). The PDBB are updated as further classifications and references are defined for the project.







Figure 19: Asset Classification aligned with configuration management gates







For TfNSW projects, often only broad locations (i.e. Complexes) are identified during feasibility. As the Systems Requirements Specification and project scope is developed, these can be aligned with element/function (EF) codes or systems codes (Ss). During detailed design products (Pr) are specified and associated with a system (Ss).

It must be noted that intricate asset systems can have child systems associated to them; for example, a Monitoring system (Ss_75_40_53) on a platform may have child systems of both a Surveillance system (Ss_75_40_53_86) and a Train dispatch CCTV system (Ss_75_40_53_90). Currently, these intricate asset hierarchies must be managed outside of many model authoring tools. The DE Framework proposes that these hierarchies are managed in the PDBB (DMS-FT-548).

Further guidance and examples of the application of asset classification are provided in DMS-SD-124 Application of Uniclass 2015 for Transport.

7.4. Discipline classification

Discipline classification enables the grouping of activities or asset by an organisational grouping, dependent on the person or group of persons responsible for the activity or asset at a particular time in the asset lifecycle. The discipline classification is categorised as either:

• Business Discipline, or

• Technical Discipline.

Discipline Classification

Systems (Ss)

Business Discipline

Technical Discipline

Figure 20: Discipline classifications

Refer to DMS-ST-207 Digital Engineering Standard, Part 2 - Requirements for TfNSW’s discipline codes and requirements for application of Discipline classification.

The DE Framework proposes that the project disciplines and their alignment with the Systems classifications are managed in the PDBB (DMS-FT-548).

7.4.1. Business discipline

Business Discipline classification enables the grouping of management activities and deliverables (Indirects) into organisational or manager codes. It is recommended that this







hierarchy be based on the business organisational chart, to ensure it is most useful for security permissions groups and workflows in content management, Work Breakdown Structure (WBS) in schedules and Cost Breakdown Structure (CBS) in cost estimates.

The business discipline should be a hierarchy that allows information to be coded to a business unit, such as safety, property, environment and planning. If needed, each of these high-level business disciplines can be broken down into practical sub-disciplines to aid in project delivery.

7.4.2. Technical discipline classification

This is a TfNSW developed classification required to enable the grouping of several Uniclass 2015 Systems into a practical Design Package (eg Civil, Electrical, Communications) and also forms part of the Work Package grouping in the cost codes and schedule WBS during the design and construction phases.

It must be noted that the Technical Discipline classification may be at a high level during the planning and preliminary design phases (Civil, Electrical, etc.), however, become more granular at the detailed design stage (e.g. Civil-Earthworks, Civil-Stormwater Drainage, Electrical-High Voltage, Electrical-Overhead Traction).

The adoption of disciplines by the project is confirmed in the PDBB and the Technical Discipline alignment with the System classification is also managed within the PDBB.

Further guidance and examples of the application of discipline classification is provided in DMS-SD-124 Application of Uniclass 2015 for Transport.

7.5. Work Packages

In general, Work Packages are a mechanism to organise project scope. During development of the project delivery strategy, the TfNSW client project team defines the structure of the project and establishes the required set of work packages.

In order to standardise how project scope is structured, and to support project benchmarking, work packages are grouped into Work Package Groups and Work Package Types (refer to Figure 21).

Figure 21 - Work Package classification

Work Package Types Work Package GroupsWork Package Types

belong to a Work Package Group

Work Package

Each Project Work Package is assigned a

Work Package Type







The main Work Package Groups of interest to Contractors are (i) Design, (ii) Supply, (iii) Construction and (iv) Commissioning. Work packages within each of these four sets are mapped to a sub-set of Project Assets, with the mapping able to vary between the different types of work packages. Figure 22 illustrates this concept of asset-related scope packaging and shows how design and construction work packages may be mapped differently. In practice, Work Packages are aligned with one or more Technical Disciplines dependent on the complexity and scale of the project.

Figure 22 Key Work Packages are mapped to Project Assets (i.e. asset-related scope packaging)

The key benefits of this approach are;

Both the client and contractor can be clear as to the scope of each project deliverable. e.g. the scope of the “Design Work Package 1” includes asset 1 & 2.

It is possible to verify that a project deliverable has accounted for all assets

It is possible to verify that the entire project scope has been accounted for across Design, Construction and Testing & Commissioning plans.

It possible to single out, where applicable, which assets are subject to special client-led supply arrangements (outside of the main contract) i.e. Supply Work Packages.

The PDBB acts as the central mechanism and the source of truth on the project for the mapping of assets and work packages.

Work packages will also be the primary mechanism used to assign responsibility of deliverables to a specific team or contractor.







8. Collaboration

Effective collaboration by the project teams is essential for realising the benefits of DE; both between TfNSW and the Contractor, and also within each Contractor team. The tools, mechanisms and individual responsibilities that will enable collaborative working, including how, where and when project information will be shared must be communicated clearly to the project team.

8.1. TfNSW and Contractor collaboration

Collaboration between TfNSW and the Contractor must be at regular intervals, appropriate to the project such that project objectives and expectations between the parties remain aligned.

Formal collaboration to facilitate design federation, reviews and approvals by TfNSW must be scheduled at appropriate milestones, to ensure design deliverables are achieved as required by TfNSW and within any constraints of the project including those discovered by the Contractor during the design process.

8.2. Contractor team collaboration

Similarly, the Contractor team, including subcontractors are recommended to engage in appropriate collaboration to:

• Achieve project objectives

• Early identification of design constraints

• Completion of deliverables as specified by TfNSW

• Sharing of information and ideas

• Identification of conflict and clashes

The timing, tools and objectives of collaboration are to be defined such that collaboration is undertaken at appropriate intervals to align with the project schedule and delivery milestones and to facilitate the completion of clear objectives/outcomes for each project phase.







9. Common data environment concepts

In a project delivery context, the CDE is the single source of information for any given project and is used to collect, manage and disseminate all relevant approved project documents for multi-disciplinary teams in a managed process (PAS 1192-2:2013).

A CDE is a collective name given to the group of integrated IT systems within an organisation that enables users to store, collaborate and exchange information and data.

Due to the DE Framework’s open data approach, the internal structure of TfNSW (i.e. different Agencies and Divisions) and the project contracting strategies, the concept of the CDE for TfNSW projects is divided into two parts (refer to Figure 23):

1. The Contractor-CDE, owned and used by the Contractor (and possibly multiple sub-contractors) for development of deliverables during the life of the project; and

2. The TfNSW-CDE, owned by TfNSW and used by the Contractor for submission of final deliverables during the life of the project. Noting; TfNSW also use the TfNSW-CDE for development of TfNSW project documents, however, this is not visible to the Contractor.

TfNSW CDE

Contractor #1 CDE

Contractor #2 CDE

Contractor #n CDE

Roads & Maritime

CouncilsProperty Owners

Utilities

TfNSW EAM

Stakeholders

O&M Phase Contractor #1

EAM

O&M Phase Contractor #2

EAM

O&M Phase Contractor #n

EAM

Asset Handover

Figure 23: Vision for Contractor-TfNSW CDE interfaces

Although there is a vision to create one whole-of-Transport CDE, the current TfNSW-CDE comprises various disparate IT systems, dependent on the Agency managing the delivery of the specific project. Contractors must confirm within the Contract or with the designated project TfNSW DE Manager the structure of the TfNSW-CDE and the most appropriate way to interface with the system(s), automated or manual, given the specific project constraints.







For the DE outcomes to be achieved, all IT systems comprising the Contractor-CDE and TfNSW-CDE for a given project need to be configured to output information and data deliverables in the formats and structure specified by this Standard. This will allow TfNSW to federate project information across multiple contracts/projects/programs into a master network model.

9.1. Approval states and suitability

To govern and control the flow of information (files) between the Contractor-CDE and TfNSW-CDE, the project is to utilise approval states and suitability. The adoption of these concepts will assist project team members in identifying the purpose of a file within either CDE. The use of approval states and suitability is defined in the sections below. The requirements for tagging files with the specified attributes is controlled as Enterprise Content Management (ECM) metadata (refer to DMS-ST-207 Digital Engineering Standard, Part2 - Requirements).

9.1.1. Approval state

As information is produced, coordinated and validated within the Contractor-CDE and submitted to the TfNSW-CDE, it must flow through a sequence of defined approval states, based on the principles of BS 1192:2007, PAS 1192.2:2013 and ISO 19650.1:2018 (refer to Figure 24).

Figure 24: Process and workflows in the CDE (ISO 19650.1)

Refer to DMS-ST-207 Digital Engineering Standard, Part2 - Requirements for DE project requirements regarding the CDE and document management within the CDE.







Appendix A - DE Framework Documents

Table 5: DE Framework project delivery documents

DE Discipline Document No.

Title Availability

All DMS-ST-208 Digital Engineering Framework Public

All DMS-ST-202 Digital Engineering Standard - Part 1, Concepts and principles

Public

All DMS-ST-207 Digital Engineering Standard - Part 2, Requirements Public

All DMS-SD-123 Terms and definitions Public

Information Management

DMS-FT-533 Enterprise Content Management (ECM) Schema and Specification

Public

Systems Engineering DMS-FT-563 Requirements Schema for DE Projects Public

CAD DMS-FT-562 CAD Schema and Specification Public

BIM Models DMS-FT-516 BIM Schema and Specification Public

Time DMS-FT-520 Scheduling Schema Public

Table 6: DE Framework delivery tools and templates


Title Availability

DE Management DMS-FT-548 Project Data Building Blocks (PDBB) Template DE Pilot Projects

DE Management DMS-FT-532 Digital Engineering Execution Plan (DEXP) Template

Public

DE Management DMS-FT-374 DE Code Request Form DE Pilot Projects


DMS-FT-555 Master Information Delivery Plan (MIDP) Template Public

CAD DMS-FT-549 Digital Engineering CAD Title Block Standard Format

Public

BIM Models DMS-FT-534 Model Production and Delivery Table (MPDT) Template

Public

BIM Models DMS-FT-556 Model Validation Certificate Public

Asset Data DMS-FT-537 Asset Register Template Public







Table 7: DE Framework technical guidance


Title Availability

All - DE Framework, The Interim Approach - Getting started

Public

DE Management DMS-SD-124 Application of Uniclass 2015 for Transport for NSW

Public

DE Management DMS-SD-145 Project Data Building Blocks Guide DE Pilot Projects

DE Management DMS-SD-143 Project Data Schemas Guide DE Pilot Projects

DE Management DMS-SD-149 Using the DEXP Public

DE Management DMS-SD-140 Project Deliverables Requirements Guide Public

DE Management DMS-SD-125 Establishing the Contractor Common Data Environment

Public


DMS-SD-128 Procurement of InEight Document Suite TfNSW only


DMS-SD-126 Using the new TfNSW InEight Document Suite DE Pilot Projects


DMS-SD-144 The Master Information Delivery Plan (MIDP) Guide

Public


DMS-SD-146 Large File Storage Guide DE Pilot Projects

Systems Engineering DMS-SD-131 Engineering Standards Mapping DE Pilot Projects

Survey DMS-SD-142 Digital Survey Requirements Guide DE Pilot Projects

CAD DMS-SD-139 The Digital Engineering CAD Concession Public

CAD DMS-FT-535 CAD Layer Naming Guide DE Pilot Projects

BIM Models DMS-SD-136 Setting up for BIM Public

BIM Models DMS-SD-137 DE Design Review DE Pilot Projects

BIM Models DMS-SD-129 Procurement of a Model Review Tool TfNSW only

Visualisation DMS-SD-130 Visualisation Requirements Guide DE Pilot Projects

Asset Data DMS-SD-141 Master Classification Library Public

Asset Data DMS-SD-138 Why not COBie Public







Appendix B – Terms and definitions

DMS-SD-123 Guide

Terms & Definitions Guide Version: 3.0 Issued date: October 2019

To be read in conjunction with DMS-ST-202 and DMS-ST-207 TfNSW Digital Engineering Standard.

Terms & Acronyms Description Reference

No.

2D 2-Dimensional representation of an object or asset with associated geometrical information attached to it in a traditional drawing-based format.

3D 3-Dimensional representation of an element or asset representing its geometrical (graphical) and non-geometrical (non-graphical) information.

4D 4-Dimensional – To link time (schedule) related data to a 3D model.

5D 5-Dimensional – To link cost related data to a 3D model.

6D 6-Dimensional – To link Asset Information to a 3D model.

A

Acquire Phase Design, Build, Integrate and Accept stage of a TfNSW Asset lifecycle.

TfNSW

Archive

Component of the Common Data Environment (CDE) where inactive or superseded information is stored. This information will provide a history of the project and can be used for contractual purposes.

BS 1192:2007 + A2:2016

ASA Asset Standards Authority is an independent unit within Transport for NSW (TfNSW) and is the network design and standards authority for defined NSW transport assets.

TfNSW








ASA Requirements

The Standards, plans, processes, procedures, instructions, requirements and guidance material (in whatever form) published externally or notified in the exercise of its functions including but not limited to any:

(a) network and asset standards (including both technical and maintenance standards);

(b) requirements for policies and processes in relation to ASA Authorisation;

(c) asset management plans, systems and processes;

(d) configuration control processes;

(e) asset and configuration data condition requirements; and

(f) asset and condition reporting requirements.

TfNSW Asset Standards Authority

As-Built / Works As Executed

Drawings that reflect the final work as executed and not the changes that have occurred during the design stages.


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

ISO 55000:2014

PAS 1192-3:2014

Asset Classification

A standardised method of identifying and grouping assets. Asset Classification is comprised of asset type, based on the Uniclass 2015 Elements/Functions (EF) and Products (Pr) tables, and asset system, based on the Uniclass 2015 Systems (Ss) table.

Asset Information Data or information relating to the specification, design, construction or acquisition, operation and maintenance and disposal or decommissioning of an asset.


Asset Information Model (AIM)

Data and information that relates to assets to a level required to support an organisation’s Asset Management System.

Often initiated from the Project Information Model on asset handover.

PAS 1192-2

PAS 1192-3

Asset Information Requirements (AIR)

Data and information requirements of the organisation in relation to the asset(s) it is responsible for.

PAS 1192-3

Asset Lifecycle An Asset’s lifecycle is its evolution from need identification through to disposal and decommissioning.

Asset Management Coordinated set of intelligent activities for an organisation to realise value from their assets.

ISO 55000

PAS 1192-3:2014

Asset Management Framework (AMF)

Defines how the requirements of the Transport Asset Management Policy are deployed, and enables Transport to manage the need for, and performance of assets and asset systems, over the full Asset Lifecycle.


Asset Management System

Management system for asset management whose function is to establish the asset management policy and asset management objectives.

In the TfNSW context, this is the Asset Management Framework.

ISO 55000

Asset Reference A brief description of an asset, used to help identify it and saved in the asset register.

Asset Register Record of asset inventory considered worthy of separate identification including associated historical, condition, construction, technical and financial information about each asset.









Attribute A piece of data forming a partial description of an object or entity. PAS 1192-2:2013

Australian Height Datum (AHD)

A geodetic datum for altitude measurement in Australia.

Authorised Engineering Organisation (AEO)

An engineering organisation that is authorised to take responsibility, on behalf of TfNSW, for assuring their engineering services or products.

In the context of PAS 1192-2:2013 an AEO can be referred to as a Task Team Author of their dedicated information.


B

Building Information Modelling (BIM)

Process of designing and constructing a building or infrastructure asset using object-based 3D modelling.

TfNSW

Business Discipline Codes used to group management activities and deliverables (Indirects).

Business Requirements Specification (BRS)

The document in which business goals and stakeholder requirements are documented.

T MU AM 06010 GU

C

Clash Rendition / Detection

Rendition of the native format model file to be used specifically for spatial coordination of discipline data (used to achieve clash avoidance or to be used for clash detection).

This is the process of ‘federating’ discipline models for the purpose of design and construction coordination.

PAS 1192-2:2013

Classification

Systematic arrangement of headings and sub-headings for aspects of construction work including the nature of assets, construction elements, systems and products.

Uniclass 2015 has been adopted as the basis of TfNSW’s classification system for use during the Plan/Acquire phase.

PAS 1192-2:2013

Construction Operations Building Information Exchange

(COBie)

Structured information for the commissioning, operation and maintenance of an asset, often in neutral spreadsheet format, that will be used to supply data to the organisation to populate decision making tools, facilities management and EAM systems.

PAS 1192-2:2013

PAS 1192-3:2014

BS 1192-4: 2014

Configuration Management Gate (CMG)

Project milestones throughout the asset lifecycle used to control and manage network configuration changes.

Different Submission deliverables are required for each CMG.

Common Data Environment (CDE)

Single source of information for any given project or asset, used to collect, manage and disseminate all relevant approved project documents for multi-disciplinary teams in a managed process.

PAS 1192-2:2013

Computer Aided Drafting (CAD)

Typically digital 2D or 3D drawings that replicate manual drafting techniques. This often involves using disconnected drawings that are manually drafted using lines, arcs and circles, which are then overlaid and coordinated in two dimensions.

T MU MD 00006 ST

Cost Breakdown Structure (CBS)

A breakdown of project expenditure that provides meaningful groupings of capital (and sometimes operational) expenditure.

The CBS is often associated with the lowest level of the WBS.








D

Demand/Need Phase Stage of an asset where the strategy is in place to execute a process prior to appointing a team.

Design and Construct (D&C)

A method to deliver a project in which design and construction are contracted by a single entity.

Design Company The party responsible for carrying out the design and drawing content on the drawing

Digital Engineering (DE)

A collaborative way of working, using digital processes, to enable more productive methods of planning, designing, constructing, operating and maintaining assets.

TfNSW

Digital Engineering Execution Plan (DEXP)

A plan that delivers and explains how the digital information management aspects of the appointment will be carried out by the service provider over the design and construction stages of a project.

TfNSW

Digital Engineering Framework (DE Framework)

Is an integrated management system that comprises of a set of documents including standards, guidelines, templates and training that provide the strategy to support a culture that enables the implementation of Digital Engineering.

TfNSW

Digital Engineering Standard (DES)

The Digital Engineering Standard is the lead document in the DE Framework, providing the minimum requirements for the adoption of Digital Engineering processes.

TfNSW

Dispose The last phase in the asset lifecycle. The end of life of a given Asset.

TfNSW

E

Engineering Company

The AEO responsible for the design on the drawing

Enterprise Asset Management (EAM)

Also referred to as an Enterprise Asset Management (EAM) system, which is a computerised system, or software that enables asset management and/or maintenance management data and activities.

TfNSW

Enterprise Content Management (ECM)

A tool (system/software) for storing, retrieving, sharing and otherwise managing electronic documents.

Also referred to as Enterprise Document Management (EDM) tool.

PAS 1192-2:2013

PAS 1192-3:2014

Enterprise document Management (EDM)

Refer to Enterprise Content Management (ECM)

F

Federation The amalgamation of discipline (task based) 3D model data in order to coordinate discipline activities in a geometrical and non-geometrical way.

TfNSW

G

Geographic Information Systems (GIS)

Systems that manage site cadastral data and associated information.

Geometrical Information

Information in a digital model that relates to the physical geometry only.

ISO 19650 (Draft)

Globally Unique Identifier (GUID)

A unique identification number automatically produced for each object with the BIM model by the authoring software.








H

Handover Asset Register

Required information from the project to be maintained/developed during the Operations and Maintenance phase

DMS-FT-537

I

Information Exchange

Structured collection of information at one of a number of pre-defined stages of a project with defined format and fidelity.

PAS 1192-2:2013


Tasks and procedures applied to in-putting, processing and generation activities to ensure accuracy and integrity of information.

PAS 1192-2:2013

Information Model

A data set comprising of documentation, geometrical (graphical) and non-geometrical (non-graphical) data.

Information Models are linked together using a common data structure (schemas) and classification system.

PAS 1192-2:2013

Industry Foundation Classes (IFC)

Industry Foundation Classes is a specification for open BIM to support an open standard for information exchange. Maintained by Building SMART International.

Building SMART International

Inspection Test Plan (ITP)

Plan outlining the required inspections or tests to be carried out to control quality of the project during construction. The ITP also forms a checklist where a log of inspections and tests can be recorded.

J

K

L

Level of Definition

The collective term used for and including the 'Level of Detail' (Graphical/Geometrical) and 'Level of Information' (non-graphical/ non-geometrical).

This is equivalent to the US BIM Forum (Building SMART US Chapter) Level of Development definition commonly used in Australia.

PAS 1192-2:2013

Level of Detail (LoD) Level of Detail is the amount of geometrical (graphical) information contained in a 3D model.

PS 1192-2:2013

Level of Information (LoI)

Level of Information is the amount of non-geometrical (non-graphical) data embedded within an Information Model.

Location Classification

Location classifications identify and group places and spaces. They are used to indicate where an asset is in relation to other assets and/or where activities take place.

M

Master Information Delivery Plan (MIDP)

A document in which the contractor identifies all of the information deliverables that will be submitted as part of the contract scope, and provide sufficient information about each item to manage delivery effectively.

Metadata Information/data used for the description and management of all geometrical (graphical) and non-geometrical (non-graphical) on a project.

TfNSW








Maintenance Managed Item (MMI)

The lowest level of the asset hierarchy where an asset is to be included in the Handover Asset Register.

Determined by the Rules for creation of assets in the asset register

(T MU AM 02001 ST Asset Information and Register Requirements, section 7.1).

Model Production and Delivery Table (MPDT)

A schedule of elements noted in a spreadsheet format to define the Level of Model Detail (geometrical) and the Level of Model Information (Non- geometrical) per element at any given stage of a project.

PAS 1192-2:2013

N

Navisworks Cache (NWC)

A file format generated by Autodesk Navisworks when opening a native CAD or laser scan file.

Navisworks Document (NWD)

A file format generated by Autodesk Navisworks, containing all model geometry together with Autodesk specific data, such as review mark-ups.

Non-Geometrical (Non-Graphical) Information

Information that relates to the data stored or linked to BIM models. ISO 19650 (Draft)

O

Organisation Information Model (OIM)

Information and data from across all departments of the organisation that provides an information data model as defined by the OIR. The information in the OIM is used to assess performance against the organisational objectives and inform high-level strategic decision-making.

Organisational Information Requirements (OIR)

Data and information required to achieve the organisation’s objectives.

PAS 1192-3:2014

Operate/Maintain Phase

The phase of the lifecycle of an asset during which the asset is used, operated and maintained.

TfNSW

P

Plan Phase The concept, specify and procurement stages of the asset lifecycle. Usually occurs within a capital project.

Project Data Building Blocks (PDBB)

The master data management tool used manage common language and coding for generating Project Data Schemas.

Project Data Schema (PDS)

The configuration specification and specific project data to be adopted from the Project Data Building Blocks for a DE discipline deliverable.

Project Information Model (PIM)

Information Model developed during the design and construction phase of a project.

The PIM contains geometric and non-geometric data and can be accessed by both the Contractor and TfNSW via the CDE.

PAS 1192-2:2013

PAS 1192-3:2014

Project Information Requirements (PIR)

Equivalent to Employer’s Information Requirements, renamed for the TfNSW context.

The information to be delivered, and the standards and processes to be adopted by the supplier as part of the project delivery process.

In a TfNSW context, Project Information Requirements are specified in the Project Contract and the Works or Services Brief.

PAS 1192-2:2013

TfNSW








Professional Services Contractor (PSC)

Consultancy offering professional services to Transport for NSW. TfNSW

Public Private Partnership (PPP)

PPP allow governments And the private sector to work together and share resources. PPP are generally considered for projects with a capital cost of more than $50 million.

National PPP Policy Framework

Published The published documentation area of the CDE is where information is moved to when it hits a milestone date in line with the project program.

BS 1192:2007 + A2:2016

R

Request for Information (RFI)

Formal project specific process, whereby the Contractor may request specific information from TfNSW. The project-specific process should be documented in the DEXP.

S

Safe Work Method Statements (SWMS)

Health and safety risk assessment

Schema The specific metadata fields and values to be complied with during the creation of DE project data.

Service Provider An organisation outside of Transport for NSW offering and delivering a service.

TfNSW

Shared When Information Models have reached a status where the information can be shared between Contractor and TfNSW they will move to this area of the CDE.

BS 1192:2007 + A2:2016

Specification The specific fields and configuration, including data formats, masks and business rules that are to be complied with during the creation of DE project data.

Submission A set or package of deliverables, of varying detail, required at each of the Configuration Management Gates.

Systems Requirements Specification (SRS)

A SRS document lists all of the requirements at the system level that describe the functions which the system as a whole should fulfil to satisfy the stakeholder needs and requirements (BRS), and is expressed in an appropriate combination of textual statements, views and non-functional requirements; the latter expressing the levels of safety, security and reliability that will be necessary.

T MU AM 06010 GU

T

Technical Discipline Codes used to group activities and deliverables associated with a physical asset group (Directs). Generally linked to an engineering discipline.

Transport Agency

Transport agencies who work across the Transport cluster which include:

Roads and Maritime Services

State Transit Authority

NSW Trains

Sydney Trains.

TfNSW

Transport Cluster

All organisations who work with and around the transport infrastructure space and represented by the Minister for Transport and Infrastructure, Minister for Roads, Maritime and Freight and Minister for Westconnex.

TfNSW








Transport for New South Wales (TfNSW)

Organisation who lead the development of safe, integrated and efficient transport systems for the people of NSW. TfNSW customers are at the centre of all activities, including transport planning, strategy, policy, procurement and other non-service delivery functions across all modes of transport - roads, rail, ferries, light rail and point to point.

TfNSW

U

Uniclass 2015 A unified classification system covering all construction sectors and items for the Construction Industry.

NBS

V

Volume

Manageable spatial subdivision of a project, defined by the project team as a subdivision of the overall project that allows more than one person to work on the project model simultaneously and consistent with the analysis and design process.

PAS 1192-2:2013.

BS1192:2007 + A2:2016

W

Work Breakdown Structure (WBS)

The WBS decomposes or subdivides the scope into more discreet and manageable, deliverable based packages of works. This provides the framework from which the project management and project control systems will be set-up to facilitate the tracking and reporting of the project status and cost (CBS).

The primary method used for grouping, sorting and organising project scope.

Work in Progress (WIP)

The WIP area of the CDE is where members of the project team carry out their own work using their organisation’s software.

BS1192:2007 + A2:2016

Work Packages Standard grouping mechanism to group design, supply, construction or commissioning activities into logical scope packages.