digital engineering standard part 2 requirements

Digital Engineering Standard Part 2 – Requirements

DMS-ST-207

Standard – Applicable to Infrastructure and Place

Divisional Management System

Status: Final

Version: 4.0

Branch: Technical Services

Section: Digital Engineering Services

Business unit:

Date of issue: September 2018

Review date: April 2021

Audience: Division wide

Asset classes: Heavy Rail; Light Rail; Metro; Roads; Bridges;

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 Digital Twin Integration


Technical Services : Digital Engineering Services :


DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207

DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207

© TfNSW 2020 UNCONTROLLED WHEN PRINTED of 116

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, systems engineering and visualisation requirements added, minor updates

4.0 April 2021 - Update for roads assets and multi-modal Configuration Management Framework







Preface

Transport for New South Wales (TfNSW) is developing and implementing the Digital Engineering (DE) Framework to support projects as they adopt new digital ways of working. The way assets are planned, designed, constructed, operated and maintained are becoming faster and more accurate as a result of emerging technologies. The DE Framework connects these technologies across various project disciplines together with reliable, structured data.

Consistent DE processes provide TfNSW with an approach that enables digital information to become a key enabler of better project outcomes. This includes, but is not limited to; stakeholder engagement, informed decision making, improved asset knowledge, capability and capacity planning.

Applying this unified vision will accelerate the value of DE, and simplify these new ways of working for both our project teams and industry, providing valuable insights, creating efficiencies and delivering cost savings throughout the project lifecycle.

This document should be read in conjunction with all related DE Framework documentation. Any application of the DE Framework 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 to ensure best appropriate practice.

Engagement with the Digital Engineering Team

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

For general enquiries and assistance with the 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 ................................................................................................................... 7

1.1. The Digital Engineering Framework ........................................................................ 7

1.2. Purpose of this document ....................................................................................... 9

1.3. Structure of this document ...................................................................................... 9

1.4. Scope of this DES .................................................................................................. 9

1.5. Terms and definitions ........................................................................................... 10

1.6. References ........................................................................................................... 10

1.7. TfNSW governance and control ............................................................................ 10

2. Collaborative working requirements .......................................................................... 13

2.1. Collaboration principles ........................................................................................ 13

2.2. Collaboration activities .......................................................................................... 13

3. The TfNSW-CDE for IP Projects .................................................................................. 14

3.1. The Contractor-CDE ............................................................................................. 14

3.2. Workflow between the CDEs ................................................................................ 15

3.2.1. Information exchange process .................................................................. 15

3.2.2. Bulk uploads ............................................................................................. 16

3.3. ECM File Metadata Requirements ........................................................................ 16

3.3.1. File name .................................................................................................. 20

3.3.2. Document title ........................................................................................... 20

3.3.3. Approval States ......................................................................................... 20

3.3.4. Suitability .................................................................................................. 22

3.3.5. Review Status ........................................................................................... 23

3.3.6. Revisions and versions ............................................................................. 23

3.4. Existing data review.............................................................................................. 25

3.5. Validation of new deliverables .............................................................................. 25

3.6. Email requirements .............................................................................................. 25

3.7. Request for Information (RFI) requirements ......................................................... 25

3.8. Data security ........................................................................................................ 26

3.8.1. Data Security Protocol .............................................................................. 26

4. Project data management ........................................................................................... 28

4.1. Project data building blocks (PDBB) ..................................................................... 28

4.1.1. Project specific building blocks .................................................................. 28

4.1.2. Standard TfNSW building blocks ............................................................... 30

4.1.3. PDBB data management features ............................................................. 32

4.2. Structuring and standardisation of data ................................................................ 33

4.2.1. Asset location containers .......................................................................... 34

4.2.2. Asset function, system and type ................................................................ 37

4.2.3. Discipline classification and referencing .................................................... 41

4.2.4. Work Packages ......................................................................................... 42

5. Management Requirements ........................................................................................ 45







5.1. Submission of DE deliverables ............................................................................. 45

5.2. Digital Engineering Execution Plan (DEXP) .......................................................... 45

5.3. Management of the Project Data Schemas (PDS) ................................................ 46

5.3.1. Changes to PDS ....................................................................................... 47

5.3.2. Changes to Uniclass 2015 ........................................................................ 48

6. Technical Requirements ............................................................................................. 49

6.1. Systems engineering deliverables ........................................................................ 50

6.1.1. Structuring and standardisation of data ..................................................... 52

6.1.2. Review of existing data ............................................................................. 52

6.1.3. Verification and validation ......................................................................... 53

6.1.4. File submission format .............................................................................. 53

6.2. Survey deliverables .............................................................................................. 54



6.2.3. Validation .................................................................................................. 59


6.3. CAD deliverables .................................................................................................. 60

6.3.1. Drawing titleblock ...................................................................................... 61

6.3.2. CAD layer naming ..................................................................................... 69

6.3.3. Composite models .................................................................................... 71


6.3.5. Validation .................................................................................................. 71


6.4. BIM deliverables ................................................................................................... 73

6.4.1. BIM process requirements ........................................................................ 74

6.4.2. BIM Model requirements ........................................................................... 76

6.4.3. Utility information ...................................................................................... 81

6.4.4. Model federation ....................................................................................... 82

6.4.5. Clash detection ......................................................................................... 83

6.4.6. Model reviewing and validation ................................................................. 83


6.5. Visualisation ......................................................................................................... 86

6.5.1. Visualisation requirements ........................................................................ 86



6.5.4. Validation .................................................................................................. 87


6.6. GIS deliverables ................................................................................................... 88

6.6.1. GIS requirements ...................................................................................... 88



6.6.4. Validation .................................................................................................. 89







6.6.5. GIS deliverable submissions ..................................................................... 90

6.7. Time deliverables ................................................................................................. 91

6.7.1. Project schedule deliverable requirements ................................................ 91

6.7.2. 4D model deliverable requirements ........................................................... 91

6.7.3. Existing data review .................................................................................. 92

6.7.4. Validation .................................................................................................. 92

6.7.5. Time deliverable submissions ................................................................... 92

6.8. Cost deliverables .................................................................................................. 93


6.8.2. 5D Model deliverables ............................................................................... 94

6.8.3. Existing data review .................................................................................. 94

6.8.4. Validation .................................................................................................. 94

6.8.5. Cost deliverable submissions .................................................................... 94

6.9. Asset data deliverables ........................................................................................ 95

6.9.1. Asset register requirements ...................................................................... 95

6.9.2. Structuring and standardisation of data ................................................... 100

6.9.3. Existing data review ................................................................................ 101

6.9.4. Validation and asset handover ................................................................ 101

7. Project team responsibilities .................................................................................... 102

8. Assurance requirements ........................................................................................... 104

8.1. Quality assurance and quality control ................................................................. 104

8.2. Performance management/ continuous improvement ......................................... 104

Appendix A - Reference of standards and guidelines ................................................... 106

Appendix B –Levels of Detail indicative diagrams ........................................................ 109

B1 Bridge Structure ................................................................................................. 110

B2 Drainage ............................................................................................................. 111

B3 Road Alignment/ Pavement ................................................................................ 112

B4 Road Furniture ................................................................................................... 113

B5 Survey ................................................................................................................ 114

B6 Utilities................................................................................................................ 115







1. Introduction

1.1. The Digital Engineering Framework

This Digital Engineering Standard (DES) and supplementary templates, guidelines training, and resources form the Digital Engineering (DE) Framework. The DE Framework provides the tools and requirements to assist TfNSW projects seeking to implement DE following the first release in 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. DMS-ST-202 TfNSW DE Standard, Part 1 – Concepts and principles 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 for the implementation of the specific requirements of the DES, based on specific DE disciplines, 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 Project Contract and/or the Project 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: Digital Engineering 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

Project Doc umen t TfNSW Guides TfNSW Template

TfNSW Procurement Templates

Supporting Documents and

Forms/Templates

Data and Information Asset Management

PolicyCP17005

Project DEXP Template & draft PDS

TfNSW Conditions of Contract

Project Scope of Works/Services

Project Specifications and Requirements

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 the implementation of DE. It details how the Data & Information Asset Management Policy (CP17005) 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 BIM Models into project delivery.

1.3. Structure of this document

This document is provided in two parts:

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

2. Part 2 (this document) – TfNSW Digital Engineering Standard, Requirements (DMS-ST-207). Providing 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 Asset Management Framework and the TfNSW Configuration Management Framework and relevant Agency configuration and design management plans.

1.4. Scope of this DES

This DES is applicable for TfNSW staff and Contractors delivering Physical Transport Assets for TfNSW during the Plan-Acquire phases (ie planning, design and construction), where DE methodologies are specified for project delivery. 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 the Digital Engineering Framework within the asset lifecycle

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 include:

• 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 DMS-ST-202 TfNSW DE Standard, Part 1 – Concepts and principles, Appendix B.

1.6. References

This DES refers to various TfNSW and industry standards, guidelines and specifications. Sources include:

• TfNSW Safety, Environment & Regulation (SER) (previously Asset Standards Authority (ASA) and Roads & Maritime Services (RMS)) standards and procedures

• Infrastructure & Place (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 Appendix A.

1.7. TfNSW governance and control

This DES references the Integrated Design Reviews, as defined in the Transport Requirements for Assured Configuration Change (TRACC) Standard, to specify the submission and deliverable requirements at the different milestones. To align the legacy ASA and RMS design assurance gates, the equivalent Configuration Management Gates (CMG) and Investment Assurance Gates (IAG) are aligned with the Integrated Design Reviews as shown in Table 1. Note, the IAG are still applicable to projects in relation to financial assurance.







Table 1: Integrated Design Reviews

Asset Management

Lifecycle

Configuration Management Framework

TRACC Standard

Design Process Configuration Management

Gate (legacy)

Investment Assurance Gate

Stage Phase Design Activity

Integrated Design Review

Demand / Need

Need (TRACC 1)

0 - Go / No Go (Needs justification)

Plan Network Planning (TRACC 2)

Feasibility Studies

CMG 0 (Business Requirements Specification)

1 - Strategic Options (Strategic assessment)

Delivery Planning (TRACC 3)

Concept Design

Concept Design Development (CDD)

CMG 1 (Concept Design)

2 - Business Case

Acquire Design (TRACC 4)

Systems Breakdown Review (SBR)

3 - Readiness for Market (Pre-tender)

4 - Tender Evaluation

Preliminary Design

Preliminary Design Review (PDR)

CMG 2 (Preliminary Design)

Reference Design (optional)

Detailed Design

Detailed Design Review (DDR)

Final Design Final Design Review (FDR)

CMG 3 (Detailed Design)

Approved For Construction

Implement (TRACC 5)

Construction Specification

Final Specification Review (FSR)

CMG 4 (Construct and install)







Asset Management

Lifecycle

Configuration Management Framework

TRACC Standard

Design Process Configuration Management

Gate (legacy)

Investment Assurance Gate

Stage Phase Design Activity


As Built As Built Review (ABR)

CMG 5 (Commissioning, testing and handover)

5 - Readiness for Service (Pre-commissioning)

Close Out (TRACC 6)

Final Build 6 – Benefits Realisation

(Post-implementation)

Operate / Maintain

Operate and Maintain (TRACC 7)

CMG 6 (Asset assurance review)

Dispose / Renew

Dispose / Renew (TRACC 8)

Refer to Section 2.1 in DMS-ST-202 TfNSW DE Standard, Part 1 – Concepts and principles for further details.







2. Collaborative working requirements

A key outcome of DE is to support collaborative working. This section defines how, where and when project information will be shared. The processes and procedures for how collaborative working will be enabled and achieved by the project are to be documented in the Project DEXP.

2.1. Collaboration principles

The Contractor must document in the Project DEXP details of the collaboration processes to be adopted, sufficient to demonstrate appropriate timing and types of collaboration to achieve the project objectives.

2.2. Collaboration activities

The Project DEXP will, at minimum, include details of relevant collaboration activities, including:

• Frequency and format of milestone information exchanges.

• How information access will be managed in accordance with TfNSW’s security requirements.

• Details of model review workshops and other collaborative working practices, for example, use of model federation and coordination at design and/or site meetings (refer to Section 6.4).

• The proposed frequency and methods for Contractor and TfNSW project stakeholders to conduct reviews using federated model/ data.

• How the handover of asset information from the Contractor-CDE to the TfNSW-CDE at the required data exchange points will be managed and recorded throughout the project.

• Quality management procedures, for example, clash detection, to ensure deliverables are assured and error free prior to submission to TfNSW.







3. The TfNSW-CDE for IP Projects

The Project CDE is made up of two parts: the TfNSW-CDE and the Contractor-CDE. This section includes the requirements and process for the submission of information deliverables by contractors to the specified TfNSW systems for scheduling, document/ file management, email and progress claims during the Plan and Acquire phases.

Standardised file formats and data structures are critical to enabling automatic data validation of submissions by TfNSW.

The current TfNSW-CDE includes the software listed in Table 2. Equivalent or additional software may be included in the TfNSW-CDE based on project specific requirements and as specified in the project Contract.

Table 2: Current typical TfNSW-Common Data Environment interface applications

Ref System Purpose Contractor Usage

1 InEight Document

(formerly TeamBinder)

Enterprise Content Management (ECM) tool

Document transmittal and management

Project communication control and governance

Transmittal of submissions and deliverables to TfNSW.

Project email and correspondence with TfNSW and Stakeholders.

2 Primavera P6 Project scheduling and construction sequencing

Upload of the agreed project schedule as per the Contract.

Reporting of progress against the planned program and milestone dates.

3 Virtual Plan Room (VPR) - ProjectWise

Rail networks only - Central plan room for rail model and drawing package submission, storage and archiving

Contractor to supply deliverables compliant with requirements for upload of models and drawings at Final Design Review and As-Built Review.

TfNSW is responsible for upload of approved models and drawings to the VPR (where applicable).

4 INX To record, manage and report on incidents, reliability issues and defects

Incidents, hazards and risks identified on the project are to be recorded directly in the INX system.

3.1. The Contractor-CDE

The Contractor-CDE, utilised by the Contractor's project team, is not limited by TfNSW's DE requirements. Any appropriate IT solution may be adopted by the Contractor that produces outputs that comply with the minimum requirements set out in this DES, including open data exchange formats and standardised project data structures specified in the PDS, to enable federation and Submission.

In relation to the CDE, at a minimum the Project DEXP is to include:







• Metadata schema for tagging files uploaded to the Contractor-CDE. It is recommended that the Contractor adopt DMS-FT-533 ECM Schema and Specification requirements to standardise the metadata tags used within the project.

• Data and information review and validation process/workflow.

• Personnel responsible for document control (validating, uploading, tagging).

• Interface with the TfNSW-CDE, including control and governance of this interface.

• Project specific CDE requirements, including the interface between the systems (manual or automated).

3.2. Workflow between the CDEs

This section explains the information requirements for all file deliverables (including documents, spreadsheets, drawings, models) exchanged from the Contractor-CDE to the TfNSW-CDE.

3.2.1. Information exchange process

With each information exchange, there are a number of steps required by the Contractor and TfNSW to ensure that the DE data and information is correct. These steps are summarised in Figure 3.







TfN

SW

-CD

EC

on

tra

cto

r-C

DE

Inte

rfa

ce

Validate data complies

with required

structures and is in

the correct format

Contractor uploads and transmits the submission

to the TfNSW receiver

Information and data

review

(metadata and schema)

Update the

comments

register

Update

submission and

respond to

comments

Are any

changes

required?

YES

NOSubmission

accepted

Technical review

START

TfNSW provide comments to

contractor via ECM interface

Figure 3: Information Exchange Process

3.2.2. Bulk uploads

Bulk upload of files to the ECM may be utilised by the Contractor. Where the metadata from the model and/or product sheet is correctly aligned with the ECM metadata requirements (refer to Section 3.3). A template for TfNSW’s ECM tool is available to facilitate this process (DMS-FT-533 ECM Schema and Specification).

3.3. ECM File Metadata Requirements

In order for the TfNSW-CDE to accept the submission as compliant, the metadata included with files uploaded to the TfNSW-CDE must align with the requirements specified in DMS-FT-533 ECM Schema and Specification. Any project specific ECM metadata requirements are to be included in the Project DEXP. Refer to Table 3 for ECM metadata requirement provisions.

Table 3: Enterprise Content Management Requirements

Ref Requirement Description

1 Metadata spreadsheet

Where TfNSW does not require the use of an ECM system solution, metadata for each file must be provided accompanying the transmission as specified in DMS-FT-533 ECM Schema and Specification in .xls format.







2 Use of ECM system solution (eg Team Binder/ InEight)

Where TfNSW specifies the use of an ECM system solution, metadata as specified in DMS-FT-533 ECM Schema and Specification must be entered upon upload of the file to the software tool.

Specific technical fields are explained in the following sections, with a summary of fields listed in Table 4 (at publication time of this Standard). Refer to DMS-FT-533 ECM Schema and Specification for the current specification and further details.

Table 4: Enterprise Content Management (ECM) Schema and Specification

Ref Field name Field Label

(TfNSW’s TeamBinder) Description

1 Document Number Document No.

Defined by Project. The unique document number required to reference the applicable document uploaded. Document number specified by the document numbering schema.

2 Document Title Title Defined by Project. The applicable title description associated with the document.

3 Program Name Program Program name defined by TfNSW.

4 Project Name Project Project name as part of a program defined by TfNSW

5 Contract Name Contract Contract reference to deliver a part of Program/Project as per the project delivery strategy. Defined by TfNSW.

6 Contracted Organisation Code

Originator The contracted organisation responsible for the production of the documents.

7 Phase Stage Code INSW Phase/TfNSW Stage

Infrastructure NSW (INSW) project governance phases and TfNSW investment assurance gates defined by TfNSW.

Visible to Document Controller only.

8 Project Milestone Code

Project Milestone Defined by TfNSW, Project specific milestone.

9 Asset Location Code (L1)

Location

Defined by Project. Refers to the top level in the asset location hierarchy to which the document refers to or belongs, e.g. Train station etc.


Sub-Location

Defined by Project. Refers to the second highest level in the asset location hierarchy, permitting documents to be associated with a more specific location

E.g. Station platform, etc.










Sub-sub-Location

Defined by Project. Refers to the third level in the asset location hierarchy, permitting documents to be associated with an even more specific location. e.g. Platform 1, Meeting Room, etc.

12 Work Zone Code (L1)

Work Zone (L1)

Defined by Project. Work Zones are where project work gets performed. Large geo-spatial areas may be sub-divided into Work Zone (L2)


Work Zone (L2) Work Zone (L2) is second level Work Zones and relate to a L1 Work Zone.


Work Zone (L3) Work Zone (L3) is second level Work Zones and relate to a L2 Work Zone.

15 Discipline Code Discipline

Defined by TfNSW. A unique identifier to identify the related Technical or Business discipline responsible for carrying out the design.

16 Sub-Discipline Code

Sub-Discipline Defined by TfNSW. A unique identifier to identify the related Technical or Business Sub-discipline responsible for the design.

17 Document Type Code

Document Type The type of information the document contains e.g. a report, drawing, etc.

18 Serial Number Serial Number

Six digit serial number which, when concatenated with the rest of the document number, results in a unique document number.

19 Document Revision Number

Revision For tagging a document with a revision reference when major changes are made.

20 Document Version Number

Version Child of Revision. Automated by system for every revisioning of the document

21 ASA VPR Discipline Code

ASA VPR Discipline Existing VPR discipline codes used by TfNSW SER (where applicable).

22 ASA EDMS ID ASA EDMS ID An allocated document identifier by TfNSW SER (where applicable).

23 ASA Amendment Number

ASA Amendment No

Document amendment number managed by TfNSW SER in relation to project milestone submissions (where applicable, refer to Section 3.3.6.1).

24 State Code State

As per ISO 19650. For tagging a document with its CDE state. E.g. Client Shared (for documents submitted to TfNSW) or Published (when authorised for use, e.g. AFC)









25 Suitability Code Suitability

As per ISO 19650. For defining the purpose or appropriate use of the document. E.g. For Coordination, For Information, For Review and Comment.

26 Review Outcome Code

Review Status

This field is not populated on upload to the TfNSW ECM but is managed automatically by the ECM tool as part of the review workflow.

27 Work Package Group

Work Package Group

The Work Package Group is a work package classification. It includes the following: “Design”, “Construction”, “Commissioning”, “Supply” & “Management”.

It is used to group Work Packages defined by the Project.

28 Work Package Name

Work Package Name

Work Packages are governed by the project based on the scope of the project. Work Packages are classified by a Work Package Group.

29 Security Classification Code

Security Classification

Information Security Classification, Labelling & Handling Standard defined according to the Information Security Classification, Labelling & Handling Standard - Policy Number: CPSt14001.4

30 BIM Reference Link BIM Reference Optional reference to models, model objects or model views.

31 GIS Reference Link GIS Reference References to GIS managed locations related to the document if required.

32 Contractor Doc Number

Contractor Doc No For the Contractor to add the Contractor-CDE Document Number, if necessary.

33 ECM Remarks Remarks User comments.

34 Date Recorded Date Recorded

The date when the document was uploaded to the ECM.

System generated.

35 Date Released Date Released

The date when the document was promoted to the Published state.

System generated.

36 Document Revision Notes

Revision Notes User comments outlining the design content and often used to denote what has changed.

37 Required for Handover Flag

Required for Handover Optional. A Y/N flag indicating whether the deliverable is required for asset handover.

38 Handover Organisation Code

Handover Organisation Optional. The organisation that is to receive the document at asset handover.







3.3.1. File name

Files uploaded to the TfNSW ECM are to be given a name that is equivalent to the Document Number with reference to file names in the Master Information Delivery Plan (MIDP), (refer to Section 5.2).

3.3.2. Document title

Document titles are required on the first or front page of each document and clearly describe their content. The same (full) title must also be captured on the transmittals and are to be included in the metadata uploaded for each document to clearly describe their content.

The document titles must include the following:

1. Begin with the project and/or location name

2. Clearly describe the content or subject matter

3. Include the type of document.

3.3.3. Approval States

The Contractor is responsible for the management of Work in Progress (WIP) and Shared information within the Contractor-CDE and uploading files to the ECM tool. All files uploaded to the ECM tool are to be tagged with the correct metadata categorisation of Client-Shared information with State (Client-Shared) and Suitability (S1, S2, S3, S4, D1, D2, D3, D4), refer to Table 6.

TfNSW or the independent certifier (if required) is responsible for the correct metadata categorisation of Review Status information within the TfNSW-CDE.

At any stage in the workflow, the information may be rejected and returned to a WIP state for further development. The approval process with corresponding states and suitability (refer to Section 3.3.4) is illustrated in Figure 4.







Figure 4: Approval States, Suitability and Review outcome

Descriptions of the approval states and their intended uses are provided in Table 5. Intermediate checking or internal states, additional to those described in Table 5, are acceptable in the Contractor-CDE, however, all these states must be defined clearly in the Project DEXP. Where the state titles used in the Contractor-CDE differ from those specified by this DES, these must be agreed with the TfNSW DE Manager prior to use.

Table 5: Application of State within the Common Data Environment

Ref State State Description

1 Work-In-Progress (WIP)

Information not checked or approved. WIP information exists only within either the TfNSW-CDE or Contractor-CDE

2 Shared Information shared within the project team for a specific purpose (refer to Table 6)

3 Client Shared Information received and distributed to appropriate TfNSW personnel or external agent (including independent certifier or verifier) for review







Ref State State Description

4 Published Coordinated and validated information which is authorised for use on the project, for example for Construction.

5 Archived Superseded or otherwise archived information

3.3.4. Suitability

Suitability codes are applied to information that is Shared, Client Shared, Published or Archived.

The Project DEXP is to specify the Suitability Codes for use on the project. On upload (Client Shared) of information to the TfNSW-CDE or after review by TfNSW, the Contractor is responsible for ensuring the appropriate Suitability Code (refer to Table 6) is included in the information metadata.

Table 6: Application of Suitability within the Common Data Environment

Ref

State Suitability Code

Suitability Title Suitability Description

1 Work-In-Progress (WIP)

S0 Not for sharing Draft information not suitable for distribution. Can be used for ‘placeholders’ in the TfNSW-CDE.

2

Shared /

Client-Shared

S1 For coordination Information shared for coordination

3 S2 For information Information shared for information only

4 S3 For review and comment

Information shared for review and comment

5 S4 For stage approval Information shared for approval at whichever project stage applies (e.g. an Integrated Design Review)

6 S5* Principal Design Party certified

Information which has been Principal Design Party (AEO, lead designer or internal TfNSW authoriser) certified (typically at Integrated Design Reviews)

7 D1 For costing Information for costing purposes

8 D2 For tender Information for tender purposes

9 D3 For contractor design

Information for contractor design purposes (e.g. shop drawings)

10 D4 For manufacture / procurement

Information for manufacture / procurement purposes

11 L1* Legacy information Historical or archived Information

12

Published

D1 For costing Information for costing purposes

13 D2 For tender Information for tender purposes

14 D3 For contractor design

Information for contractor design purposes (e.g. shop drawings)







Ref

State Suitability Code

Suitability Title Suitability Description

23 D4 For manufacture / procurement

Information for manufacture/procurement purposes

20 A1 Note submission with no further comments

Stage completed with no further comments. TfNSW is ready to proceed to the next stage (for example, construction).

Principal Design Party (AEO, lead designer or internal TfNSW authoriser) responsibilities are unaffected by the application of this code.

21 A2 Note submission with further comments

Stage completed but with comments to address during the next stage.

Principal Design Party (AEO, lead designer or internal TfNSW authoriser) responsibilities are unaffected by the application of this code.

22 AB As-Built Information published as an As-Built record

23 Archived Any Any Any of the above suitability codes may apply to information in the Archived state.

3.3.5. Review Status

Review Status codes are applied to information in the TfNSW-CDE during the review workflow. The values shown in this table may vary between projects.

Table 7: Application of Review Status within the TfNSW-Common Data Environment

Ref Type Review Status Code

Review Status Description

1 Released REL-COM Released subject to comments

2 Released RELEASED Released (released for information only – no review required)

3 Rejected REV-RES Revise and resubmit (document not fit for release)

4 Released REV-RNC Released with no comments (no outstanding comments)

3.3.6. Revisions and versions

TfNSW requires all information within the Contractor-CDE and TfNSW-CDE to be revision and version controlled (refer to Table 8).







3.3.6.1. Revision

At each submission of a file from the Contractor-CDE to the ECM tool within the TfNSW-CDE, the ECM revision must be incremented. The first issue of design drawings must begin at ‘A’ if prior to Approved For Construction (AFC) and 00 if AFC or beyond.

Where required by SER (formerly ASA), the Contractor must control the revisions of all engineering drawings (.dgn, .dwg and .pdf) and models (refer to Section 6.4) uploaded to the VPR (at Final Design Review, Final Specification Review and As Built Review) and as required by the project CAD requirements (typically for ‘rail’ projects only). This revision numbering is known as the ASA Amendment Level Revision.

Note, the Contractor is not required to upload directly to the VPR, but is required to provide TfNSW with information compliant with the file formats, file naming and metadata required for VPR upload.

Refer to Section 6.3 for DE discipline specific (BIM Model and CAD drawing) revision and version control. Any project specific requirements stated in the Project DEXP.

Table 8: Revision and version control within the TfNSW-Common Data Environment

Ref Deliverable Type File Formats

Uploaded to TfNSW-CDE

Frequency (minimum)

Revision Numbering Standard

1 All deliverables excluding Engineering drawings and models

As required by the Contract

ECM All milestones, including Integrated Design Reviews, as specified in the Contract.

IP Document Number, Titling and Revisioning Procedure

2 Engineering drawings

.dgn or .dwg and.pdf


Project CAD Requirements

3 Engineering models

As required by the DEXP


DMS-FT-532 DEXP Template

3.3.6.2. ECM Version

The TfNSW ECM tool governs the ECM Version property automatically: when a new revision is added to the TfNSW ECM tool, its version is set to ‘0’. On occasions that a file is replaced or adjusted without a new revision being assigned, the version number is incremented automatically.

The ECM Version is a TfNSW ECM property and is different from the Contractor’s version number in a drawing titleblock. The version shown on a drawing is not required to match the ECM Version in the TfNSW ECM. Refer to Section 6.3 for details. An example of the progression of revision and version numbering through the project life is provided in Table 9.







Table 9: Example Document Revision Progression

ECM State ECM Suitability

ECM Revision (Contractor revision)

ECM Version (TfNSW version)

ASA Drawing Rev (VPR AMD)

Submission 1 S3 A 0

TfNSW Returned with Comments

A 1

Submission 2 S3 B 0

Endorsed by TfNSW B 1

Published (AFC) D3 00 0 A

AFC updated during construction

D3 01 0 B

As-built AB 01 1 C

The application of this revision numbering for a project is to be clearly articulated for the project team in the Project DEXP.

3.4. Existing data review

Existing data and information is to be reviewed for relevancy to the project. Where existing data is to be re-used as part of a new deliverable, this data must be classified in accordance with this DES, if not already compliant.

3.5. Validation of new deliverables

Deliverables (files) submitted to TfNSW will be verified to ensure compliance with the ECM metadata schema specified in the Project DEXP. Submissions that do not comply with these requirements will be returned to the Contractor for correction.

3.6. Email requirements

Communication by email is used within a project for both informal and formal correspondence. Project related email communications are to be maintained as part of the project record. Where TfNSW requires the use of an ECM tool by the project, project emails to TfNSW or nominated project stakeholders are to be communicated via the nominated ECM tool.

Project specific requirements for the classification and management of email files are to be included in the Project DEXP or other appropriate project management plan. Classification of emails includes security classification based on the NSW Government Dissemination Limiting Marker (refer to the ECM Schema and Specification in the Project DEXP).

3.7. Request for Information (RFI) requirements

Where TfNSW requires the use of an ECM tool by the project, the Contractor must submit all RFIs using the ECM tool.







3.8. Data security

TfNSW DE projects must balance the project specific needs of confidentiality, integrity and accessibility with the consequences of any loss or unauthorised release of the information, whether of a personal or business nature.

For all built assets, specific security measures related to information exchange will be identified by TfNSW on a project-by-project basis and communicated to the Contractor and its supply chain accordingly.

3.8.1. Data Security Protocol

The Contractor is required to comply with all relevant TfNSW security standards and obligations (refer to T MU AM 02004 ST Management of Asset Information).

The Project DEXP must demonstrate how the Contractor will manage and monitor compliance against these security requirements. At a minimum, the Contractor will provide a Data Security Protocol (DSP) in the Project DEXP that outlines security protocols to be implemented for the project. The DSP will address:

1. Data protection, including documenting the mitigation strategies that will be implemented to protect systems and data. The eight essential mitigation strategies identified by the Australian Cyber Security Centre that are should be addressed are summarised in Table 10.

2. User access rights and permissions:

i. list all the project roles defined in this DES and the Project DEXP who will

have access to data, and

ii. For each role identified, list the specific data access rights.

Table 10: Essential Eight Strategies to Protect Data (https://www.cyber.gov.au/acsc/view-all-content/essential-eight/essential-eight-explained)

Ref Risk Applied protection measures

1 Non-approved applications

(including malicious code) may be

executed

Application control to prevent execution of

unapproved/malicious programs including .exe, DLL,

scripts (eg Windows Script Host, PowerShell, and

HTA) and installers

2 Security vulnerabilities in

applications can be used to execute

malicious code on systems

Patch Applications e.g. Flash, web browsers,

Microsoft Office, Java, and PDF viewers.

Patch/mitigate computers with ‘extreme risk’

vulnerabilities within 48 hours. Use the latest version

of applications

3 Microsoft Office macros can be used

to deliver and execute malicious

code on systems

Configure Microsoft Office macro settings to block

macros either in ‘trusted locations’ with limited write

access or digitally signed with a trusted certificate

4 Flash, ads and Java are popular

ways to deliver and execute

malicious code on systems

User application hardening. Configure web browsers

to block Flash (ideally uninstall it), ads and Java on

the internet. Disable unneeded features in Microsoft

Office (e.g. OLE), web browsers and PDF viewers

https://www.cyber.gov.au/acsc/view-all-content/essential-eight/essential-eight-explained

https://www.cyber.gov.au/acsc/view-all-content/essential-eight/essential-eight-explained







Ref Risk Applied protection measures

5 Adversaries use these administration

accounts to gain full access to

information and systems

Restrict administrative access to operating systems

and applications based on user duties. Regularly

revalidate the need for privileges. Do not use

privileged accounts for reading email and web

browsing

6 Security vulnerabilities in operating

systems can be used to further the

compromise of systems

Patch operating systems Patch/mitigate computers

(including network devices) with ‘extreme risk’

vulnerabilities within 48 hours. Use the latest operating

system version. Do not use unsupported versions

7 Stronger user authentication makes

it harder for adversaries to access

sensitive information and systems

Multi-factor authentication including for VPNs, RDP,

SSH, and other remote access, and for all users when

they perform a privileged action or access and critical

(sensitive/high-availability) data repository

8 Access to data could be lost either

through deliberate attack such as a

ransomware incident or due to

accidental damage to system

infrastructure

Daily backups of important new/changed data,

software and configuration settings, stored

disconnected, retained for at least three months. Test

restoration initially, annually and when IT infrastructure

changes

Project specific cybersecurity requirements, such as provision of a Service Organisation Control (SOC) 2 audit report, are addressed on a project by project basis and included in the project contract.







4. Project data management

TfNSW requires projects to develop, implement and maintain procedures to manage data and information across the project lifecycle. TfNSW defines minimum data requirements that must be adhered to by a Project at key project milestones. These data requirements are reflected in the structure of the Project Data Building Blocks (PDBB) and associated Project Data Schemas (PDS). Contractors must comply with the data requirements specified in this Standard and the PDS.

At the conclusion of the project setup, the content of the PDS should be agreed and confirmed by TfNSW and the Contractors, ready for design to commence.

4.1. Project data building blocks (PDBB)

At the commencement of each project phase, the TfNSW project team will establish the PDBB, utilising DMS-FT-548 Project Data Building Blocks Template. Control and governance of the PDBB during the life of the project remains with TfNSW. The PDBB are periodically updated by TfNSW based on the scope of the project, development of the design and the increasing level of understanding, including improved understanding of:

• The optimal location breakdown

• Asset systems and types incorporated in the design and delivery

• The parties engaged in the execution of the project

• How the project scope is grouped into work packages.

The PDBB will be confirmed for the stage by TfNSW and used to generate the PDS for inclusion as an appendix in the DEXP template. This Project DEXP template may be issued to market as part of the tender documents (refer to Section 5.3).

The PDBB datasets included in DMS-FT-548 Project Data Building Blocks Template includes:

Project specific building blocks (summarised in Table 11)

Standard TfNSW building blocks (summarised in Table 12)

The PDBB contains features that provide users with functionality to assist with managing PDBB data and the publishing of PDS (summarised in Table 13).

4.1.1. Project specific building blocks

The project specific building blocks included in the PDBB Template (DMS-FT-548), that must be defined by the project team at project commencement are listed in Table 11.







Table 11: Project Data Building Blocks – Project Specific Building Blocks

Ref Building block dataset

Purpose

1 Project Details Specifies the Program & Projects and, as per the project delivery strategy, the list of logical Project Contracts for each project.

Following procurement, Organisations can be associated with Project Contracts.

Able to map various IT system identifiers to Programs, Projects and Contracts as and when they are instantiated in TfNSW corporate systems.

2 Asset Locations Specifies all asset locations applicable to the project. Each location is named and classified with Uniclass 2015.

A location hierarchy is defined to reflect the asset location-to-asset location relationships.

This hierarchy may include the full enterprise context; however, projects can indicate which three levels of locations are applicable for referencing documents in an enterprise contentment management (ECM) system.

3 Assets The asset list specifies all assets applicable to the project. Each asset is named and classified with Uniclass 2015.

TfNSW standard Asset Type Codes are also assigned to assets to allow for grouping of assets for the purpose of reporting & benchmarking.

An asset hierarchy is defined to reflect asset-to-asset relationships.

The Asset list provides the mapping between assets and asset locations.

The Asset list also allow for assets to be associated with work packages (defined in the Work Packages tab) are to reflect scope packaging decisions during Design, Construction and Commissioning. Assets may optionally be assigned to supply work packages if certain assets are supplied outside of the normal construction contract arrangements.

4 Work Packages Work Packages are defined as part of the project work breakdown structure (WBS) development.

Work Packages are included with the PDBB to allow for the association of Work Packages with Assets.

Logical contracts (defined in the Project Details tab) are assigned to Work Packages to reflect the delivery strategy.








Purpose

5 Work Zones Work Zones are geo-spatial boundaries that define where project work gets performed.

Work Zones can be organised into Work Zone Groups.

A hierarchy of work zones can be defined to allow for large geo-spatial areas to be sub-divides as required.

Ownership of work zone defined can be established to allow for TfNSW to, for example, control top-level work zones and the contractor to organise more refined, delivery-focused work zones.

The PDBB is used to record the Work Zone Group and Work Zone relationships. The geo-spatial properties of Work Zones should be managed in each BIM and GIS model as spaces/containers or shape files.

6 Asset Stewards Allows for shorting listing of organisations who will play the role of asset owner, asset operator and asset maintainer.

7 Asset Locations to Work Zone Matrix

This matrix allows for Asset Locations and Work Zones to be mapped.

Mapping implies that there some geo-spatial overlap between the Work Zone and an Asset Location.

8 Work Package to Work Zone Matrix

This matrix allows for Work Packages and Work Zones to be mapped.

Mapping implies that Assets within the scope of a Work Package are associated with a Work Zone.

4.1.2. Standard TfNSW building blocks

The datasets listed in Table 12 are managed globally by TfNSW. Each project imports a specific version of these datasets and, where permitted, may modify this data by either controlling the visibility of codes (e.g. refer to Disciplines) or adding custom values (e.g. refer to Project Milestones).

TfNSW Standard Building Blocks may not be modified without permission from TfNSW.

Table 12: Project Data Building Blocks – TfNSW Standard Build Blocks


Purpose

1 Discipline Specifies TfNSW Business and Technical Disciplines. Disciplines are defined at two levels: discipline and sub-discipline.

Projects are permitted to edit the visibility of Disciplines on projects via the PDBB.

2 Asset Status The Asset Status is a set of SER defined codes to indicate the status of assets. An Asset Status is applied to both existing assets and planned assets by the project team.








Purpose

3 Contract Types A Contract Type denotes the type of commercial contract.

A Contract Type is applied to each Project Contract in the PDBB.

4 Co-ordinate System

A global set of co-ordinate systems permitted by TfNSW.

5 Document Type The standard list of recognised document types.

6 Drawing Type The standard list of drawing types.

7 INSW Phase TfNSW Stage

Standard list of INSW Phases/TfNSW investment stages.

8 Originators List of originators (or Organisations) managed by TfNSW. This table also flags if an organisation is an Authorised Engineering Organisation (AEO) or an authorised design company.

9 Project Milestone

Standard list of IP Project Milestones.

Note, there are minor differences in the set of milestones used on rail and road projects. The Project Milestones master data list supports both requirements and it is up to the project to select which set to use. This is achieved by specifying “Road” or “Rail” as an attribute of the Program in the PDBB.

Custom milestones specific to a project may also be added to the Project Milestone list in the PDBB.

When Project Milestones are published via the PDS, only relevant Project Milestones are copied as per the above.

10.1 State Standard set of document State codes.

Used in the ECM to indicate the approval level and appropriate use of information.

See ISO 19650 and BS 1192:2007.

10.2 Suitability Standard set of document Suitability codes.

Used in the ECM to indicate the approval level and appropriate use of information.

See ISO 19650 and BS 1192:2007.

10.3 Review Outcome

Standard set of Review Outcome codes.

Used in the ECM to attribute documents under review.

11 Security Classification

Standard list as per 'NSW Government Information Classification, Labelling and Handling Guidelines.

12 Work Package Groups

A Work Package Group is a classification of Work Packages.








Purpose

13 Work Type A standard list of verbs used to describe the type of work being performed. Separate lists are maintained for association with Asset Locations and Work Packages.

14 Location Classification

Holds a copy of all Uniclass 2015 codes that are used to classify asset locations. This includes codes from the following Uniclass 2015 tables: Co – Complexes, En – Entities and SL – Spaces/Locations.

Only one Uniclass version of each table is used at any time.

15 Asset Classification

Holds a copy of all Uniclass 2015 codes that are used to classify assets. This includes codes from the following Uniclass 2015 tables: Ef – Elements/Functions, Ss - Systems and Pr – Products.

Only one Uniclass version of each table is used at any time.

4.1.3. PDBB data management features

Functions and features built into the PDBB Template (DMS-FT-548) are described in Table 13.

Table 13: Project Data Building Blocks – Data Management Features

Ref Feature Purpose & Overview

1 Standard Version Control Records the versions of all Standard TfNSW building blocks.

This includes the versions, and release dates of all TfNSW master data and Uniclass 2015 tables.

The Standard Version Control information is published via the DE Project Data Schema templates to inform all recipients what version of master data is to be used on a project.

2 Data Quality Dashboard A set of data validation checks that compare PDBB data with the auto generated PDS data with the PDBB.

It can assist users with identifying if PDBB data has changed and differs from the last published set of PDS data allowing PDBB user to determine if PDS data needs to be re-distributed.

3 Update Uniclass Tables Ability to import and refresh the copy of Uniclass 2015 tables stored within the PDBB to manage the version of asset location and asset classification codes used on a project.

Automatically updates the Standard Version Control data.

4 Update TfNSW Master Data Ability to import and refresh the copy of Standard TfNSW master data from centrally managed and version-controlled source.







Ref Feature Purpose & Overview

5 Update a PDS from Project Data

Ability to auto-generate & refresh a PDS dataset from the PDBB including:

Asset Register PDS

BIM PDS

CAD PDS

ECM PDS

Scheduling PDS

6 Export PDS to Schema Template

Ability to copy the relevant PDBB-managed data into the distributable DE Schema Templates.

This feature ensures that the Schema Templates only contain the latest version of the PDS data and a copy of the Standard Version Control information.

The distributable DE Schema templates are cleaned up to remove any embedded links to source documents.

The following DE Schema Templates are suppoted:

DMS-FT-333 ECM Schema and Specification

DMS-FT-516 BIM Schema and Specification

DMS-FT-520 Scheduling Schema

DMS-FT-537 Asset Register Template

DMS-FT-555 Master Information Delivery Plan Template

DMS-FT-563 CAD Schema and Specification

4.2. Structuring and standardisation of data

All deliverables (geometric and non-geometric), including drawings, models, engineering artefacts, documents and datasets must be appropriately classified in accordance with this DES, applicable Guidelines and Asset Custodian requirements. In addition, the data and information contained within deliverables, including 3D objects, CAD layers and asset information, also require classification.

For projects delivered under the DE Framework, data and information must be classified by:

• Asset location containers

• Asset function, system and type

• Work Package (Design, Supply, Construction, Commissioning)

• Discipline.

The general application of each of these classification types is provided in the sections following. The specific classification requirements for deliverables are provided in Section 5. The application of classification and referencing for the project is to be managed through a







change control process using DMS-FT-548 PDBB Template and propagation of changes to the Contractor via reissuing of PDS.

Refer to DMS-SD-124 Application of Uniclass 2015 for Transport for further guidance and examples demonstrating the application of classifications in a project context.

4.2.1. Asset location containers

Deliverables created by DE-enabled projects are required to apply standardised classification and referencing for the location container(s) to which they are associated. The specific requirements for each dataset type are specified in Section 6 and the relevant PDS. Location classification and referencing requirements are summarised in the following sections.

4.2.1.1. Asset location classification

Asset location classification is used during the acquire phase, for project delivery. The TfNSW DE Framework mandates the use of the Uniclass 2015 Complexes (Co), Entities (En) and Spaces/Locations (SL) classification tables to describe the various asset location containers/groups of assets within common locations (refer to Table 14).

Table 14: Asset location classification categories aligned with Uniclass 2015

Ref Classification Description Relevant Classifications

1 Asset Location The location of an asset or group of assets (where the asset is) For example a railway station, road carriageway or railway line.

Complexes (Co)

Entities (En)

Spaces/Locations (SL)

During the life of the project, the application of the asset location classifications increases in granularity, with minimum classification requirements aligned with the Integrated Design Review milestones. A summary of these requirements is provided in Table 15.

Table 15: Minimum Asset location classification Requirements (Uniclass 2015)

TRACC Integrated Design Review Minimum classification required

Co En SL

3 Concept Design Development Co_xx

and

En_xx

and / or

SL_xx

4 Systems Breakdown Review Co_xx_xx En_xx_xx SL_xx_xx

Preliminary Design Review Co_xx_xx En_xx_xx SL_xx_xx

Detailed Design Review Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx

Final Design Review

5 Final Specification Review Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx

As Built Review

4.2.1.2. Referencing of asset locations

A reference is a name and/or an identifier and is essential to uniquely identify each item within the information model.







Each Asset Location in the asset location hierarchy must be correctly referenced.

References are to be applied by the Contractor and are to be consistent with existing naming conventions, including T MU AM 01007 TI Asset Reference Codes Register. Existing TfNSW locations, including references, are provided by TfNSW as part of the PDS.

All new location references proposed by the Contractor during project development are to be submitted to TfNSW for approval, utilising DMS-FT-374 DE Code Request Form. Upon agreement with TfNSW and documented in the Project DEXP.

The fields used for Asset Locations referencing are listed in Table 21.

Table 16: Asset Location Referencing Fields

Field Name Description

TfNSW Asset Location ID Provided by TfNSW.

Unique across TfNSW.

Project Asset Location ID A unique number that is allocated to the asset location for the duration of the contract;

This unique number enables searching for and tracking of assets and related asset data, attributes and documents and serves as the primary key for an Asset Location and hence it is mandatory.

Asset Location Code Asset Location Codes are governed by TfNSW, some at an enterprise level and some at the project level.

The Asset Location Code is a human-readable alternative primary key for an Asset Location.

The asset location breakdown is normally agreed between Contractors and TfNSW.

Each Asset Location Code must be unique across the project / program (and where appropriate across TfNSW).

For new asset locations, the Asset Location Code must be agreed with SER. Should SER deem there is no requirement to develop a centrally governed Asset Location Code, the project can create an appropriate Asset Location Code to suit the project needs.

Mandatory field.

The value is automatically derived by concatenating the Location Code Part from all locations in the location hierarchy.

The length of the Asset Location Code is therefore dependent on the hirerachy. It is a text field.

As there are no limits to the depth of the asset location hierarchy, there are no limits to the length of this code, however, it is unusual for there to be more than 6 levels in an asset location hierarchy.

Asset Location Description The Asset Location Description is a description governed by SER for the Asset Location. This description directly related to the Location Part Code for the Asset Location.

For new asset locations, the Asset Location Description must be agreed with SER. Should SER deem there is no requirement to develop a centrally governed Asset Location Description, the project can create an appropriate Asset Location Description to suit the project needs.

An Asset Location Description determined by SER will be unique within its parent location container. If the project team develop their own program/project based Asset Location Description then this description should be unique to the program/project.

A description used for the Asset Location Description for an Asset Location at level 1 (Asset Location Description (L1)) will be governed by SER.







Figure 5 provides an example of location classification and referencing. Refer to TfNSW Application of Uniclass 2015 (DMS-SD-124) for further guidance.

Asset Location Classification:

SL_80_10_10 Bus stops

References (Asset Location Description):

Stand A Stand B Stand C Stand D


SL_80_50_24 Double-sided platforms

References (Asset Location Description):

Platform 1 Platform 2


SL_80_35_13 Carriageways

References (Asset Location Description)::

M1 Northbound M1 Southbound

Figure 5: Examples of Asset Location classification and referencing

4.2.1.3. Work Zones

Work Zone location containers may be used by projects to assist with project delivery (refer to DMS-ST-202, Section 6.2.2 for more information on the use of Work Zones). TfNSW requires that the projects govern Work Zone definitions. This process is led by the TfNSW project team and in collaboration with contractors. Work Zone definitions must include the both the Work Zone references, relationships and geometry information, as summarised in Table 17.

Table 17: Work Zone data


Work Zone Group Name The name of the a Work Zone Group to allow for multiple sets of work zones.

Work Zone Group Code A code for the Work Zone Group.

The Work Zone Group Code must be unique on a project.

Work Zone Code The primary human-readable code for the Work Zone.

It is recommended that the Work Zone Group Code is incorporated into the Work Zone Code

Work Zone Codes should reflect the level of a work zone in a work zone hierarchy.

For example: WZG1.01.01 would be imply a level 2 work zone belonging to a Work Zone Group called WZG1

Parent Work Zone Code Use to establish a parent-child relationship between Work Zones

Work Zone Name A descriptive title for the Work Zone

Work Zone Owner Indicates who is is responsible for managing the work zone geometry.







The PDBB is used to manage the Work Zone data and this data is shared across the project for use in producing deliverables via the PDS. Contractors requiring changes or additions to Work Zones must use the DMS-FT-374 DE Code Request Form to agree changes with the TfNSW project team.

Projects must define how Work Zones and their associated geometry will be governed during the project, for example, by using spaces/containers or shape files in the BIM Model or GIS. This process must be documented in the Project DEXP.

The DES recommends that top-level work zones are governed by the TfNSW project team and child work zones are managed by the Contractor.When defining child Work Zones, these must be fully contained within the geo-spatial definition of the parent Work Zone.

Figure 6: Work Zone and Sub Work Zone definition (references & geometry)

4.2.2. Asset function, system and type

Deliverables created by DE-enabled projects are required to apply standardised classification, coding and referencing for the asset function, system and type to which they are associated. The required asset classification and referenceing for each deliverable are specified in section 6 and the relevant PDS. Asset classification and referencing requirements are summarised in the following sections.

4.2.2.1. Asset classification

All asset information must be classified with a common language and structure, based on the Uniclass 2015 classification system.

The TfNSW DE Framework uses the Uniclass 2015 Elements/Functions (EF), Systems (Ss) and Products (Pr) classification tables to describe the type of a physical asset (refer to Table 18).







Table 18: Asset classification categories aligned with Uniclass 2015

Ref Classification Description Relevant Uniclass 2015 Classifications

1 Asset Element A generalised description of a main asset component or function.

For example, Vehicular paving or Rail tracks.

Elements/Functions (EF)

2 Asset System An individual or group of asset types that together perform a specific function (the purpose of the asset). For example, Stone mastic asphalt paving systems or Ballasted rail track systems.

Systems (Ss)

3 Asset Product An individual asset or component (what the asset is) For example, Stone mastic asphalt (SMA) surface courses or Bullhead rails.

Products (Pr)

During the life of the project, the application of the asset classification increases in granularity, with minimum classification aligned with the Integrated Design Review milestones (refer to Table 19).

Table 19: Minimum Asset Classification Requirements (Uniclass 2015)

TRACC Integrated Design Review

Minimum classification required

EF

Ss Pr

3 Concept Design Development EF_x

and

Ss_xx

and

As required

4 Systems Breakdown Review EF_xx_xx Ss_xx_xx As required

Preliminary Design Review EF_xx_xx Ss_xx_xx_xx Pr_xx_xx

Detailed Design Review EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx

Final Design Review

5 Final Specification Review EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx

As Built Review

The following rules must be followed to provide traceability, demonstrate relationships and asset function (refer to Figure 7 for an illustrative example):

Every asset type (Pr) identified in the Asset Register must be associated with a corresponding system (Ss), and recorded in the Project Asset Register.

Every asset system (Ss) identified in the Asset Register must be associated with a corresponding element/function (EF), and recorded in the Project Asset Register.







Figure 7: Example of relational classification requirements

The assets must be defined to the level of the Maintenance Managed Item (MMI, the lowest level of the asset hierarchy where an asset is to be included in the Handover Asset Register) by Final Design Review. To determine the MMI, refer to the rules for the inclusion of assets in the asset register as specified in T MU AM 02001 ST Asset Information and Register Requirements, section 7.1 Rules for creation of assets in the asset register.

Refer to the contract and Project DEXP for confirmation of project asset classification requirements over and above the minimum requirements included in this DES.

If Uniclass 2015 does not provide an appropriate classification, the Contractor is to request a new code via DMS-FT-374 DE Code Request Form. TfNSW will facilitate the creation of new codes from NBS (the custodian of Uniclass 2015), as required.


4.2.2.2. Asset type code

As specified in Section 6 and the relevant PDS, an Asset Type Code is to be provided to compliment the asset information. The Asset Type Code is to be sourced from existing TfNSW internal data standards as appropriate to the project scope. A library of Uniclass 2015 classifications and their related Asset Type Code is provided in the Master Classification Library (DMS-FT-141).







Where further granularity is required for design or specification purposes, the project may utilise the Asset Type Configuration Code function.


4.2.2.3. Referencing of assets

A reference is a “name” and/or an “identifier” and is essential to uniquely identify each item within the information model.

Each Asset in the asset hierarchy must be correctly referenced. The fields used for Asset referencing are listed in Table 20

Table 20: Asset Referencing Fields


TfNSW Asset ID Provided by TfNSW.

Unique across TfNSW.

Project Asset ID A unique number, usually system generated, that is allocated to the asset for the duration of the contract.

This unique number enables searching for and tracking of assets and related asset data, attributes and documents and serves as an the primary key field for an Asset and hence is mandatory.

Asset Code The Asset Code is formula-derived using a combination of the the Asset Type Code (refer to Section 4.2.2.2) and asset instance and takes into consideration the parent-child relationships within the asset hierarchy. The value can be automatically generated within the PDBB.

Note, the Asset Code is only unique within the scope of a single Assset Location. The same code could exist on other projects and at other locations which have the same assets and asset parent to child relationships. For example, two similar bridges are likely to have similar Asset Codes.

If the asset has a parent, then the Asset Code will be a concatenation of the parent's Asset Code and this asset's Asset Type Codes and Asset Identifier (if defined). The length of code is determined by the concatenation and depends on the depth of the parent and child relationship.

Asset Code naming conventions with example

Asset Type Code (of parent): “VT” (vertical transport)

Asset Type Code (of this asset): “LIFT” (passenger lift)

Asset Code (of this asset) = “VT.LIFT”

If the Asset Instance field is used, an example Asset Code will be =

“VT.LIFT_001”

Asset Description The Asset Description contains a title or short description the specific level of the asset corresponding to the Asset Code.

Where an asset description is not available within TfNSW asset standards, the Contractor should propose a description for review and approval by TfNSW. If similar/duplicate assets are used within one project location, a unique identifier is to be included in the reference (for example ‘Bicycle Rack 1’ and ‘Bicycle Rack 2’).

References are to be applied by the Contractor and created in compliance with T MU AM 02001 ST Asset Information and Register Requirements and T MU AM 01006 ST Asset Location Classification. References are to be consistent with existing TfNSW naming conventions as required by the Contract, including:

T MU AM 02002 TI Asset Classification System







T MU AM 01007 TI Asset Reference Codes Register

Roads and Maritime Services Schedule of Classified Roads and Unclassified Regional Roads

ILC-GEN-TP0-901 Asset Acceptance Technical Procedure

Bridge Inspection Procedure Manual.

The Contractor is to create an asset list to control and manage a project’s full list of Elements/Functions, Systems, Products and associated data. The asset list must comply with the schema specified in the DMS-FT-537 Asset Register Template to facilitate data transfer in and out of the BIM model(s) and enagement with the O&M function. Refer to Section 6.9 for more information regarding Asset data.

4.2.3. Discipline classification and referencing

The TfNSW DE Framework mandates the classification of data and information by Discipline, a classification based on the specialism or organisational unit/team associated with a task, activity, information or asset. Discipline classification must be categorised as either Business Discipline or Technical Discipline, as described in Table 21.

Table 21: Project Discipline classification categories

Ref Classification Description Relevant Classifications

1 Technical Discipline

A functional grouping that provides asset specific classification of tasks, activities, deliverables or data, based on the engineering unit responsible.

For example, Civil or Electrical engineering.

TfNSW defined (refer to Table 22)

2 Business Discipline

A functional grouping that provides system-wide (not asset specific) classification of tasks, activities, deliverables or data, based on the business unit responsible.

For example, Sustainability, Scheduling, Contracts Administration.

TfNSW defined (refer to Table 22)

Project information and data is to be classified with a Discipline Code, as per Table 22. Sub-discipline codes may also be utilised by the project. Confirmation of the Discipline and Sub-







discipline codes to be utilised by the project and their application will be defined by TfNSW in the PDS for consistent application across the project.

TfNSW manages the versions of Discipline and Sub-discipline Codes and the contractor will be notified via the PDS of the discipline codes relevant to the project.

Table 22: Discipline Codes (refer to the project PDS for the project-specific discipline codes)

Ref Discipline Type Discipline Code Description

1 Technical AR Architectural

2 CO Communication

3 CV Civil

4 EL Electrical

5 FE Fire

6 FL Fleet Systems & Equipment

7 GN General

8 HY Hydraulic

9 ME Mechanical

10 SG Signalling & Control

11 ST Structural

12 TE Technology

13 UT Utilities

14 Business CM Commercial Management

15 CX Construction Management

16 CY Community

17 DV Development Management

18 EN Environment & Planning

19 OP Operation Management

20 PC Project Controls

21 PM Project Management

22 PP Property

23 SF Safety

24 SN System Engineering

25 CI Cyber Secruity

4.2.4. Work Packages

Contractors will be provided with all project defined Work Packages via the PDS.

Each project work package includes the following information:







Work Package Code

Work Package Name

Work Package Group, which refers to the work package classification

The scope of each work package, which lists all assets (and their corresponding Technical Disciplines and locations) that are relevant to the individual work package.

The Contractor must comply with the TfNSW issued Work Packages across all PDS that refer to Work Packages.

When referencing a Work Package in a project deliverable, the full scope of the Work Package must not contradict the scope associated with that Work Package in the project deliverable. For example, in a project Schedule, a schedule activity that references a Work Package must only include assets referred to in the Work Package definition.

The Contractor may propose changes to the scope of a Work Package. For example, if an asset was previously not identified and is being added, the definition of a Work Package changes correspondingly as illustrated in Figure 8 (note, System B is new).

Element / Function

(Asset L1)Location A

System A

Asset (L2)

Product A1

Asset (L3)

WG01.01 – Design WP 1

System B

Asset (L2)

Product A2

Asset (L3)

Figure 8: Changing the scope of Work Packages

The Contractor is free to define additional granularity to a work package hierarchy provided by TfNSW so long as the additional Work Packages always roll-up to the TfNSW issued Work Packages as illustrated in Figure 9 (Contractor adds child work packages highlighted in green).







WG01.01 – Design WP 1

WG01.01.01 – Design WP 1.1

WG01.01.02 – Design WP 1.2

Figure 9: Contractor defined "child" Work Packages

4.2.4.1. Work Package Groups

The DES defines four classifications of work packages, referred to as Work Package Groups. The purpose of Work Package Groups is to identify and group work packages used on projects at different phases of the project lifecycle. Table 23 lists all Work Package Groups

Table 23: Work Package Groups

Work Package Group ID

Work Package Group

Purpose

WG01 Design To identify and group all “design” work packages together.

WG02 Supply To identify and group any “supply” work packages together.

Use of supply work packages is optional. They are needed only when there are specific supply arrangements for assets outside of the typical construction contracts.

WG03 Construction To identify and group all “construction” work packages together.

WG04 Commissioning To identify and group all “commissioning” work packages together.

Used when the project requires the commissioning of assets to be done in a manner that differs from how they are constructed.

Where required by the PDS, the contractor must maintain a record of the associated Work Package Group for a deliverable.







5. Management Requirements

Management requirements are specified to assist the project team in implementing appropriate control, coordination and governance during the DE process. Management tools include the DEXP, PDS, communications and document control. The full suite of project specific management requirements are included in the Project DEXP.

5.1. Submission of DE deliverables

Information can be formally submitted to TfNSW at any time during the course of a project phase, with contractual Shared and Published Submissions (refer to Section 3.3) usually aligned to the Integrated Design Reviews, refer to Section 1.7 for further details. These Submissions inform whether the design meets the business and system requirements or justifies the decision to invest in the next phase.

The frequency of Submissions will be defined within the Contract, which is to be reflected in the Project DEXP and project schedule.

Based on the requirements of the Contract, the project schedule will document the agreed dates for the upload of submissions based on contract deliverable dates. The Contractor will be responsible for collecting and collating the required information and making the submissions in accordance with the Contract.

A summary of Submission requirements is provided in DMS-SD-140 Project Deliverables Requirements Guide to be used as a checklist to facilitate compliance with this DES. It is to be noted that additional project specific requirements may be included in the project contract or Project DEXP.

5.2. Digital Engineering Execution Plan (DEXP)

The primary tool for the management of DE during the project is the Project DEXP. Requirements defined by TfNSW in the DE Standard and contract documents are reflected by the Contractor in the Project DEXP. Deliverables planned to fulfil the scope are detailed by the Contractor in the Master Information Delivery Plan (MIDP).

The TfNSW project team will provide the Contractor with a Project DEXP template, based on DMS-FT-532 DEXP Template, which includes the MIDP Template (DMS-FT-555).

The Project DEXP and the MIDP are to be actively managed and updated throughout the course of the project to ensure that they align with the project scope, DE strategy, contract structure and available resources (tools/IT systems and personnel). The Project DEXP is to be submitted for TfNSW review and approval at the minimum project milestones as stated in Table 24.







Table 24: Digital Engineering ExecutionPlan submissions


Document Type

Description/Purpose Minimum Requirement

3 CDD DEXP TfNSW approved document detailing the Contractors methodology, controls and governance of the DE process.

As per the project specific DEXP Template, based on DMS-FT-532 DEXP Template

4 SBR DEXP Updated for the subsequent Preliminary Design stage.

PDS relevant to the project developed to reflect and provide cross-reference and/or integration with the project System Requirements Specification (SRS) breakdown.


PDR DEXP Updated for the subsequent Detailed Design stage.

PDS updated to reflect and provide cross-reference and/or integration with the project System Requirements Specification (SRS) breakdown and sub-system breakdown.


DDR N/A - -

FDR DEXP Updated for the Construction stage, as required.


5 FSR N/A - -

ABR N/A - -

It is important that the Project DEXP is updated to include any approved changes to the PDS.

TfNSW will provide PDS with the project specific DEXP template (based on DMS-FT-532 DEXP Template). Refer to Section 5.3 for requirements for management of the PDS.

5.3. Management of the Project Data Schemas (PDS)

The PDS is a collective term given to all schemas, specifications and templates that are required to standardise data across each DE discipline. TfNSW uses the PDBB to generate the PDS issued to the Contractor as part of the Project DEXP template.

During the life of the project, strict governance and change control of the PDS must be implemented. A list of the current DE schemas and templates that make up the PDS is provided in Table 25.







Table 25: DE Project Data Schemas

Ref DE Discipline Project Data Schema or Guide Document

Number

1 Documents (all files transmitted

to TfNSW via the ECM tool) and

correspondence

ECM Schema and Specification DMS-FT-533

2 Systems engineering Requirements Schema and

Specification

DMS-FT-563

3 Surveys Project specific requirements are to be

specified in the project contract and/or

Project DEXP. Refer to the Digital

Survey Guide for project guidance.

Utility Schema and Specification

DMS-SD-142

DMS-FT-493

4 CAD drawings CAD Schema and Specification DMS-FT-562

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

6 Visualisation Project specific requirements are to be

specified in the project contract and/or

Project DEXP. Refer to the Visualisation

Requirements Guide for project

guidance.

Visualisation utilising the BIM Model as

a basis, is to comply with the BIM

Schema and Specification.

DMS-SD-130

DMS-FT-516

7 GIS QA Specification G75 Geographic

Information Systems (GIS)

GIS Schema

IC-QA-G75

DMS-FT-580

8 Time Scheduling Schema DMS-FT-520

9 Cost estimating Specified by project - schema currently

outside the scope of DES Release 4.0.

Pending

10 Asset data Asset Register Template DMS-FT-537

Each schema above defines the specific metadata or data structures that the Contractor must comply with when submitting a deliverable related to that DE discipline.

5.3.1. Changes to PDS

During the project, the Contractor is encouraged to collaborate with TfNSW to ensure that the PDS remains practical. Particularly that the locations and work packages remain aligned with the Contractor’s actual design and construction methodologies as closely as practicable.

Where the values available for a field are defined by TfNSW in the PDS, Contractor proposed changes, modifications or additions are to be developed in collaboration with the project’s TfNSW DE Manager. Once finalised, DMS-FT-374 DE Code Request Form is to be completed







by the project team and TfNSW DE Manager and submitted to the TfNSW DE Team for approval.

When agreed, the project’s TfNSW DE Manager will then update the PDBB and reissue the impacted PDS. On receipt of a new or updated code from TfNSW, the Contractor is required to update all affected data to ensure it remains aligned and reflected in all subsequent deliverables.

TfNSW will endeavour to accommodate any code requests, however, proposed changes will be evaluated against impacts to all interfacing datasets and systems across TfNSW, including the OIM, PIM, AIM and benchmarking.

5.3.2. Changes to Uniclass 2015

If a project identifies the need for a new Uniclass 2015 code, the project’s TfNSW DE Manager is to complete DMS-FT-374 DE Code Request Form and submit this to the TfNSW DE Team. The TfNSW DE Team will liaise with NBS (the custodian of Uniclass 2015) on behalf of the project to discuss changes to Uniclass 2015 table(s). Changes agreed by NBS will be provided to the project team.







6. Technical Requirements

Provided in the following sections are the required deliverables aligned with the DE disciplines, noting that several are placeholders for future releases of the DE Framework:

Table 26: Release coverage of Digital Engineering disciplines

DE discipline Release 1 Release 2 Release 3 Release 4 Future Releases

Systems engineering

Survey

CAD

BIM (3D)

Visualisation

GIS

Time (including 4D)

Cost (including 5D)

Asset data (including 6D)

Note: the scope of coverage for each discipline will be incrementally addressed as the DE Framework is developed and the best appropriate practice established by our DE-enabled Projects.







6.1. Systems engineering deliverables

Within the Systems Engineering discipline, ‘a system is a combination of hardware, software, people, processes, and support arrangements that meet customer needs as a product or services. A system can include data, facilities, materials and naturally occurring features’ (T MU AM 06006 ST Systems Engineering Standard).

This DES defines the linkage between a requirements management system and structured data (defined in the PDBB and PDS) for the delivery of physical infrastructure assets. As such, the current scope of Systems Engineering for DE-enabled projects, as defined by this Standard, is limited to:

The acquisition of physical infrastructure assets

Requirements Management deliverables.

DE-enabled projects delivering Systems Engineering outcomes, as specified in T MU AM 06006 ST Systems Engineering Standard, are required to align the project requirement definition, where appropriate, with DMS-SD-563 Requirements Schema and Specification.

DMS-SD-563 Requirements Schema and Specification has been developed in compliance with T MU AM 06004 ST Requirements Schema to include cross-reference to appropriate PDBB, to meet DE project specific needs. The inclusion of additional data is as permitted by the standard (T MU AM 06004 ST Requirements Schema, 6.2 Requirements management information).

The linkage of requirements management artefacts with the PDS, assists the project team by:

Providing a standard framework to define and communicate the physical project scope which is scalable, repeatable and auditable.

Utilising common coding, including standard work package structures and Uniclass 2015 classification, within the Business Requirements Specification (BRS)/System Requirements Specification (SRS) and other Systems Engineering deliverables, so that traceability and verification/validation of physical asset requirements is facilitated.

Systems Engineering deliverables for DE-enabled projects, aligned with the Integrated Design Reviews, are specified in Table 27.







Table 27: Systems Engineering Deliverables for Digital Engineering projects


Deliverable DE Requirement

3 CDD Operation Concept Definition

Maintenance Concept Definition

Business Requirements Specification (BRS)

Operation and maintenance requirements are allocated to an appropriate:

system or asset (Uniclass 2015 EF, Ss or Pr code) and/or

asset location (Uniclass 2015 Co, En or SL code).

OCD and MCD requirements and associated classification and coding reflected in the BRS, developed utilising DMS-SD-563 Requirements Schema and Specification, and as specified by T MU AM 06006 ST Systems Engineering Standard.

4 SBR System Requirements Specification (SRS)

System and sub-system breakdown defined based on OCD, MCD and typical System Breakdown Structure (refer to DMS-SD-141 Master Classification Library).

SRS developed utilising DMS-SD-563 Requirements Schema and Specification, and as specified by T MU AM 06006 ST Systems Engineering Standard.

Identified systems allocated into design/work packages in collaboration with development of the commercial and procurement strategy development.

Defined Asset Locations, Systems/Assets, design/work packages and work zones are documented in the PDDB and PDS.

PDR SRS developed

Verification and Validation

Additional systems and/or sub-systems identified during design process documented in the SRS, PDBB and PDS.

Traceability of design elements to business and system requirements demonstrated utilising DMS-SD-563 Requirements Schema and Specification, and as specified by T MU AM 06006 ST Systems Engineering Standard.

DDR SRS developed

Verification and Validation

Additional systems and/or sub-systems identified during design process documented in the SRS, PDBB and PDS.


FDR

5 FSR Verification and Validation


ABR







6.1.1. Structuring and standardisation of data

Each requirement documented in accordance with DMS-SD-563 Requirements Schema and Specification, must be classified using Uniclass 2015 codes to the levels specified in Table 28 and Table 29, as a minimum and aligned with the PDS.

Table 28: Minimum Location Classification Requirements (Uniclass 2015)

TRACC Integrated Design Review Co En SL


and

En_xx

and / or

SL_xx

4 Systems Breakdown Review Co_xx_xx En_xx_xx SL_xx_xx



Final Design Review


As Built Review


TRACC Integrated Design Review EF Ss Pr

3 Concept Design Development EF_xx

and

Ss_xx

and

As required




Final Design Review


As Built Review

6.1.2. Review of existing data

Any existing data is to be reviewed for accuracy and degree of useability and relevance to the project. Where existing data is to be re-used as part of a new deliverable, this data is to be classified in accordance with this DES, if not already compliant.

Existing and/or legacy data available to the project, must be verified against the existing conditions for any discrepancies and assessment of accuracy. Depending on the outcomes, a decision will be made on the reliance of any existing Systems Engineering deliverables for further use on the project.

All major discrepancies with existing information must be discussed and a resolution agreed with the TfNSW DE Manager before being used on TfNSW projects.







6.1.3. Verification and validation

Prior to submission to Integrated Design Reviews, TfNSW will assess Systems Engineering data for compliance with the classification requirements and DMS-SD-563 Requirements Schema and specification, as agreed and documented in the Project DEXP.

Verification and validation for the project must be in accordance with the requirements of T MU AM 06006 ST Systems Engineering Standard. Where possible, the Contractor is to utilise the BIM Model and the structured ECM to demonstrate and link requirements to verification or validation evidence.

6.1.4. File submission format

Systems Engineering deliverables and any project specific processes or tools to be utilised in the development and delivery of the submissions are to be documented in the Project DEXP.

DE projects are required to structure system engineering requirements data in accordance with DMS-SD-563 Requirements Schema and Specification.

Systems Engineering deliverables are to be provided in both native (eg ReqIF) and .xls format and uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3. Alternatively, where provided by the project, Systems Engineering deliverables may be authored directly in the TfNSW’s DOORS database.

Systems Engineering deliverables uploaded to the TfNSW ECM tool are to be named in accordance with the ECM tool requirements specified in Section 3.3, with any departures or qualifications to these requirements documented in the Project DEXP.







6.2. Survey deliverables

TfNSW relies on surveys to support the development and use of infrastructure and facilities. Surveys provide a range of critical information to inform planning and development of infrastructure projects, including detail information on existing conditions, verification of as-built assets, and documenting existing assets through measured surveys. It is critical for DE projects to receive survey deliverables in suitable formats to support the DE development and delivery process. Note that the information provided in this section apply to surveys supporting DE enabled projects, but can also be used for non-DE projects.

The types of surveys typically required across the asset lifecycle include:

• Existing condition surveys – surveys that capture existing conditions, with the aim to provide input into the evaluation of, design, and construction of projects, including:

o Topographical surveys, which measures existing features and the elevation of points on an area of land

o Cadastral surveys, which establishes, or re-establishes, the boundaries of an area of land using a legal description

o Engineering surveys, which establishes the existence, physical condition and structural stability of an area, including surveys of structures, buildings, utilities and the environment, capturing either surface or sub-surface features, or both

• Construction surveys – surveys which set out the reference points and markers that guide the construction of new structures and buildings

• As-Built surveys – surveys which document the location and condition of recently constructed elements of a project, including construction verification and change detection

• Measured surveys – surveys to document existing assets, capturing both graphical and non-graphical information

• Control surveys – surveys to establish reference points (control networks) for other surveys connected to either the TfNSW survey control network (e.g. inside the heavy rail corridor) or with the NSW state survey control network.

Figure 10 shows the typical application of different types of surveys across the TfNSW asset lifecycle phases.







Figure 10: Types of surveys across the asset life cycle

Projects must work closely with the relevant TfNSW surveyors on the appropriate standards, requirements and guidelines to use for a survey project. More information on relevant points of contact for TfNSW surveyors are provided in DMS-SD-142 Digital Engineering Survey Requirements Guide.

Table 30 provides an overview of the regulatory requirements for surveys relevant to NSW, and also lists other standards, requirements and general guidance to be considered when conducting surveys.

Table 30: Acts, Regulations, Standards and Guidance

Type Description

Acts and Regulations Relevant acts and regulations for New South Wales include:

NSW Surveying and Spatial Information Act 2002

NSW Surveying and Spatial Information Regulation 2017

NSW Surveyor General’s Directions

NSW Conveyancing Act and Regulations

NSW Registrar General’s Directions

Standards Key standards related to surveying for TfNSW, include:

HR Railway Surveying – T HR TR ST 13000

AS 7634:2017 Railway Infrastructure – Surveying

AS 5488-2019 Classification of Subsurface Utility Information (SUI)

The Australian Survey Control Network (SP1)

Australian Map and Spatial Data Horizontal Accuracy Standard (2009)







Type Description

Guidance Specifications, guides and manuals informing survey requirements, including:

DMS-FT-493 Utility Schema and Specification

HR Engineering Drawings and CAD Requirements - T MU MD 00006 ST

Sydney Metro Survey Technical Guide

QA Specification G71 – Construction Surveys

QA Specification G73 – Detail Survey

CADD Manual (3.2. CADD Manual Surveying)

TfNSW Geospatial Datum Modernisation Policy (CP20001)

TfNSW Geospatial Modernisation Guiding Principles

Technical Direction Surveying – Implementation of revised Geocentric Datum of Australia (GDA) GDA2020 (SVTD 2019/01 / RMS.19.1346)

GDA94 Technical Manual GDA2020 Technical Manual

TfNSW has adopted GDA2020 as the standard datum for all spatially referenced data from 1 January 2020. For further information on adoption of GDA2020 consult the guidance documents referenced in Table 30.

Deliverables must comply with the existing domain specific survey standards, which must be defined in the contract on a project-by-project basis. Depending on the project’s specific surveying needs the deliverables may include delivery of:

• Point Cloud Data – a data set produced from a laser scan survey, which captures existing conditions to a high level of detail. Point clouds are a deliverable in their own right and may be supplemented with videos and photographs

• 2D CAD – survey results can be supplied as 2D CAD files or 2D string model, which from a DE perspective may limit the usability of the information supplied, but are useful for traditional mapping activities

• 3D CAD – survey results can be delivered as 3D CAD files or 3D string model. 3D PDFs may also be required to eliminate the need for specialist CAD or other viewing software

• Digital Elevation Models (DEM) – includes Digital Terrain Models (DTM) and Digital Surface Models (DSM) where DTM represents the elevation of the bare ground of a terrain, while DSM represents the elevation of a terrain including vegetation (e.g. trees) and man-made features (e.g. buildings)

• 3D Models – based on point cloud data converted to 3D Object Models, which may incorporate information from other sources such as existing 2D drawings, photos, videos, etc.

• Imagery – images increase the quality of information captured during a survey and can be used to identify and extract features, and support 3D model development

• Survey Control Points – represents the project control network used for the survey and must be integrated with existing rail control or state control network







• Survey Validation – confirms the quality of the survey points, including that the survey has achieved the expected levels of accuracy

• Metadata Statement – a metadata statement must be provided with the main survey deliverables to support interpretation and re-use of the survey deliverables

• Reports – standard survey deliverables must be accompanied by the relevant reports providing information on data collection, data processing, geo-referencing, and outcomes from the survey.

Table 31 outlines the typical deliverables required for each of the survey types, with deliverables marked as “Y” to be included, “O” as optional, and “-“ not required.

Table 31: Survey deliverables matrix

Type of Survey

Existing Conditions As-Built

Deliverables

To

po

gra

ph

ical

Cad

astr

al

En

gin

ee

rin

g -

Su

rfac

e

En

gin

ee

rin

g -

Su

bsu

rfa

ce

Co

nstr

ucti

on

(set-

ou

t)

Co

nstr

ucti

on

Veri

ficati

on

Ch

an

ge

Dete

cti

on

Measu

red

Co

ntr

ol

Point Cloud Y - Y - - Y Y Y -

2D CAD Y Y Y Y Y Y Y Y Y

3D CAD Y Y Y Y Y Y Y Y Y

Mesh Models Y - O - - O O O -

3D BIM Models - - Y Y - Y Y Y -

Imagery O O Y Y Y Y Y Y -

Survey Control Points

Y Y Y Y Y Y Y Y Y

Survey Validation

Y Y Y Y - Y Y Y Y

Metadata Statement

Y Y Y Y - - - - Y

The deliverables include control network information and survey metadata, to enable the re-use of the survey data and results by TfNSW and Contractors. More information on survey deliverables are provided in DMS-SD-142 Digital Engineering Survey Requirements Guide.


The classification of survey data is linked to the intended use as well as the primary domain (rail, roads, maritime, etc. assets) the project is conducted in. Appropriate classification of surveyed and 3D modelled data (scan to 3D models) is key to the ongoing effective use of the survey deliverables.







Laser scan survey data points (point cloud data) are typically initially classified based on the type of objects scanned, e.g. bare ground, building, vegetation, etc. This initial classification serves as the basis for identification of the features captured in the point cloud data set. Depending on the intended use the point cloud data is then processed to identify strings, planes (surfaces) and objects.

Surveys that are to be used as input for data modelling (scan to 3D models) to modelled data require classification of both surface and underground features. For these survey deliverables the following classifications are to be used:

Surveys of surface features, in particular those that support the development of a 3D object based model (i.e. scan to 3D model), adopt the data classification (location, asset and discipline) and referencing as outlined in Section 4

Surveys of utility services inside the metropolitan rail area must comply with the Detailed Site Survey (DSS) requirements listed in Engineering Drawings and CAD Requirements - T MU MD 00006 ST, which defines the standard codes representing services and their installation type within the rail corridor

Surveys of all other underground utility surveys utility services outside the metropolitan rail area must comply with DMS-FT-493 Utility Schema and Specification and AS 5488:2019 - Classification of Subsurface Utility Information (SUI), as well as discipline classification as outlined in Section 4.2.3

Surveys of roads including road-bridges must comply with the classification requirements outlined in QA Specification G73 – Detail Survey

Survey strings must be in accordance with the relevant domain standards and / or requirements.

Classifying surveys correctly, in particular 3D objects and models extracted from surveys, enables the project team to use this information for planning, design, construction and operations & maintenance in a consistent manner.

Where there is a conflict between different standards and requirements due to the multi-mode nature of the project the Rail standard requirements take precedence, unless otherwise agreed with TfNSW.


Existing survey data and information provided is to be reviewed for relevancy to the project. Where existing survey information is to be utilised as a part of the project, this data is to be validated and verified in accordance with this DES, if not already compliant. Projects must also confirm relevancy and applicability of existing survey data with the appropriate TfNSW surveyor.

When reviewing existing data note that all infrastructure projects currently underway are to maintain the previously set construction datum (i.e. GDA94 or ISG 66 for certain rail alignment projects), unless it is cost effective to convert them to GDA2020. For all infrastructure projects currently underway but with future stages about to commence design, GDA2020 should be used for the future stage, unless the future stage designs must be spatially integrated with an earlier project stage. For further information consult the GDA2020 guidance documents referenced in Table 30.







6.2.3. Validation

All survey deliverables produced during the project will be data validated at key milestones of the project. Validation will be for compliance with the relevant domain survey standards, alignment with the PDS, and compliance with the Contractor’s Survey Management Plan and/or Project DEXP.


The type and format of survey deliverables must align with the existing file format requirements of the relevant transport or asset owner domain. Guidance on preferred file formats for survey deliverables is provided in DMS-SD-142 Digital Engineering Survey Requirements Guide. TfNSW project teams must specify their project-specific requirements, based on the project objectives, in the contract.

Survey deliverables are to be submitted to TfNSW in agreed formats and identified within the Project DEXP and uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3.







6.3. CAD deliverables

As part of TfNSW’s DE Framework, the 2D CAD drawings will remain as one of the primary deliverables of exchanging design drawing information for projects to submit at each Integrated Design Review. The CAD standards to be adopted are as specified in the contract CAD requirements and to be read in conjunction with the Project DEXP.

To maintain the integrity of the information, as a minimum, the following process must be implemented when producing 2D CAD deliverables.

• For consistency, all 2D and 3D CAD data must be derived from the BIM Models as required by TfNSW (refer to Section 6.4).

• There must only be one drawing sheet per drawing number as a drawing file output.

• Drawings must have reference files (eg Xref) unbound (dwg or dgn) to form part of the submission in accordance with the contract CAD requirements.

• Where linear assets are represented, the native 3D model remains the source of true geometry and alignment. A LandXML or native file format of the alignment must be included as part of CAD submissions to assist in maintaining the integrity of the geometry.

• All drawings must be identified using the unique file metadata tagging as described in Table 4 for upload to the ECM.

• If legacy CAD backgrounds are used to produce plan layouts, it is essential they are only used as a guide and not traced or embedded inside models.

Where a project is delivered in compliance with this DES, at a minimum CAD deliverables must be submitted in accordance with the contract CAD requirements. Where the DE requirements specified in this DES do not comply with the TfNSW CAD standards, a concession/departure has been agreed with TfNSW stakeholders.

The CAD deliverables required are as per the project contract and in accordance with Table 32, noting the DE Specific Requirements included in Section 6.3.1. Submission of CAD deliverables is to be in accordance with the requirements of the contract and documented in the Project DEXP.

Table 32: CAD submissions


Document Status at Submission Milestones

Description/Purpose

3 CDD Concept Design Drawing

Initiation of communicating design intent for a project.

4 SBR - -

PDR Preliminary Design Drawing

Used for capturing design intent, to assist in high level decision making and cost-estimation for tendering.

DDR Detailed Design Drawing

Completed drawings for submission to TfNSW for certification.








Document Status at Submission Milestones

Description/Purpose

FDR Approved for Construction Drawing

Certified by TfNSW for construction.

5 FSR Red-line mark-ups Used to capture any changes that have occurred during construction. Used as an interim reference prior to completion of As Built drawings.

ABR As Built Drawing A record of the completed works

6.3.1. Drawing titleblock

The requirements for the DE drawing titleblock must comply with the procedure explained in the following sections. The fields and format have been based on TfNSW CAD requirements and modified to enable digital ways of working, including alignment with both Project DEXP and ECM requirements in Section 3.3. Any variations on the drawing titleblock must be agreed with TfNSW and the project team before proceeding.

DMS-FT-549 DE Title Block Standard Format A1 H_Typical provides the approved TfNSW DE drawing sheet templates, which includes amendment of the following five components:

• drawing details box

• sign-off box

• amendment box

• cover sheet details

• drawing frame details.

Refer to Table 33, Table 35, Table 36, Table 38 and DMS-FT-562 CAD Schema and Specification for additional DE data standardisation requirements. All data entry fields in the five components are attributes included as part of ECM metadata and BIM Models.

The TfNSW attributes naming must be adopted unless otherwise agreed with the TfNSW DE Manager to suit the different authoring software platform. The additional metadata fields enable the setup of DE projects in the 3D information modelling environment and achieve consistency and alignment with TfNSW CAD requirements.

The following terms and definitions are used in this standard:

• design company as the design company responsible for carrying out the design and drawing content on the drawing

• engineering company designated the Principal Design Party (AEO, lead designer or internal TfNSW authoriser) responsible for the design on the drawing.







6.3.1.1. Drawing details box

The drawing details box provides details of the drawing subject matter and contains information about the drawing title and revision.

Figure 11 shows the different fields in the drawing details box.

Figure 11: Drawing details box on a typical TfNSW Digital Engineering drawing sheet

Table 33 provides the details of the fields in the drawing details box at the time of publication of this Standard. Refer to DMS-FT-549 and DMS-FT-562 CAD Schema and Specification for the current specification and further details.

Table 33: Drawing details box – Digital Engineering attributes description

Ref Field Name Business Definition Attribute

1 Asset location description

A description of the location, governed by SER.

tbLocality

2 Corridor and kilometrage

Corridor and kilometrage reference as per T MU MD 00006 ST Engineering Drawings and CAD Requirement for rail projects, or road number and name for road projects

tbLine

3 Job description detail 1

Project description. Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details

tbDetail1

4 Job description detail 2

Design work package name. Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details

tbDetail2

5 Drawing type Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details

tbDetail3

6 Drawing details/ Chainage range

Optional field used to provide extra drawings details or chainage range

tbDetail4

7 Drawing set number

Allocated drawing registeration number used by the Plan Management Centre (roads)

tbDrawingSetNo








8 Part number The drawing Part number used to subdivide the drawing packages to support delivery phase, leave blank if not required

tbPartNo

9 Sheet number Refer T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details

tbSheetNo

10 Total number of sheets

Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details

tbOfSheets

11 Sheet size Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details

tbSheetSize

12 Document purpose

Indicate the status of the drawing related to the project milestone stage

tbStatus

13 Bridge number The Bridge number used by road bridge as a reference required for O&M phase, leave blank if not required. To obtain a new Bridge number please check with the TfNSW Project Team.

tbBridgeNo

14 Design company document number

The document number include the Project Contract code, Organisation code, Location or Sub-Location code, Discipline or Sub-Discipline code, Document type and Drawing Serial number.

tbAEODrgNo

15 Project contract Code

The Project Contract Code is a key that identifies a logical contract on a project.

TfNSW_ProjectContractCode

16 Contracted organisation code

AEO or Engineering Company Code for the organisation responsible for the documents. The unique company code is provided by TfNSW document control.

TfNSW_ContractOrgCode

17 Asset location code (L1)

A sub-set of all Asset Location Codes. This sub-set if limited to all Level 1 locations as defined by the project.

TfNSW_AssetLocationCodeL1







20 Discipline code Technical or Business Disciplines Code that is controlled by the MDBB.

TfNSW_DisciplineCode

21 Sub-discipline code

Related Technical or Business Sub-disciplines Code that is controlled by the MDBB.

TfNSW_SubDisciplineCode

22 Document type code

A unique code for identifying a specific type of document.

TfNSW_DocumentTypeCode

23 Serial number Six digit serial number which, when concatenated with the rest of the document number, results in a unique document number.

TfNSW_SerialNo

24 Design company revision

Indicate the design company revision level related to the design company document number.

tbAEORevNo








25 Design company version

Indicate the design company version level.

tbAEOVerNo

26 ASA VPR discipline code

A SER allocated discipline code used in the Virtual Plan Room repository.

tbVPRDisciplineCode

27 EDMS ID A SER allocated document identifier that is mapped to a project document.

tbEDMSID

28 EDMS amendment level

Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details

tbAMDNo

The fields in the drawing details box are a combination of either text field or number attributes with a pre-defined list in ECM tool and DMS-FT-562 CAD Schema and Specification.

For fields with ‘text field’, the information shall conform to the following principles:

• Drawing titles shall be correct, comprehensive and compliant with the formats indicated

• Abbreviations or codesshall be used in accordance with the ECM metadata or ones that are explained on the drawing using common construction abbreviations (for example, LV, HV and FE)

• The drawing title shall contain specific information about the content of the drawing. After a drawing is submitted to the SER VPR (where applicable), the drawing title shall not be modified in future amendments.

The Design company (Contractor) revision field in the drawing details box shall be in alignment with the latest revision attribute in the Amendment box and numbering as per Section 3.3.5.

As a minimum, all DE projects shall conform to the following principles:

• All drawing deliverables shall include both Design company revision and version number information when issued to TfNSW

• The revision number shown in the drawing titleblock must match the TfNSW ECM tool revision number when issued to TfNSW

• The Design company version number shown on a drawing is not required to match the ECM Version in the TfNSW ECM tool. The ECM Version is a different property for TfNSW and will default to zero for each new revision. Refer to Section 3.3. for ECM requirements.

Table 34: Examples of Revision and Version number at various project phases

Contractor Virtual Plan Room

REV VER Description Submission AMD No.

A 0 ISSUED FOR CONCEPT DESIGN DEVELOPMENT

Not Req. Blank ()

A 1 ISSUED FOR COORDINATION Not Req. Blank ()

B 0 ISSUED FOR PRELIMINARY DESIGN REVIEW Not Req. Blank ()







Contractor Virtual Plan Room

REV VER Description Submission AMD No.

00 0 AFC ISSUED BY CONTRACTOR (POST FDR APPROVAL OF DETAILED DESIGN)

Required A

01 0 RE-ISSUED FOR CONSTRUCTION (MINOR DESIGN CHANGES DURING CONSTRUCTION)

Not Req. A

02 0 RE-ISSUED FOR CONSTRUCTION (POST FDR APPROVAL FOR MAJOR DESIGN CHANGES)

Required B

98 0 AS BUILT ISSUED BY CONTRACTOR (POST ABR APPROVAL)

Required C

99 0 AS BUILT ISSUED BY CONTRACTOR (POST DEFECTS LIABILITY PERIOD APPROVAL)

Not Req. C

Where required by TfNSW, all rail drawings lodged and uploaded to VPR, the VPR discipline code, EDMS ID and AMD number fields shall be filled in and information maintained throughout the required submissions. All road drawings lodged to the Plan Management Centre must including the Drawing Registeration Number (Drawing Set Number) and the metadata spreadsheet as per Section 6.3.6.

6.3.1.2. Sign-off box

The sign-off box shall contain the full names of the persons who have performed the design, design check, drawing, drawing check and approval of the document at the time of final preliminary design, approved for construction or subsequent design change. These fields shall not be updated for drawing amendments when there is no design change.

Note: Where the first name of a person is too long to fit within the space provided in the sign-off box, the first initial and last name of the person is acceptable.

Figure 12 shows the different fields in the sign-off box.

Figure 12: Sign-off box on a typical TfNSW Digital Engineering drawing sheet







Table 35 provides the details of these fields at publication time of this Standard. All data entry fields in the sign-off box should be populated as attributes and included as part of the ECM metadata. Refer to DMS-FT-562 CAD Schema and Specification for the current specification and further details.

Table 35: Sign-off box – Digital Engineering attributes description


1 AEO engineering company name

The AEO engineering company name. tbAEOSuppName

2 Design company name

The Design company name is confirmed with TfNSW document control and is associated to the Design company code.

tbDesignCompName

3 Discipline description The Discipline or Subdiscipline description. tbDiscipline

4 Branch name The Branch name within TfNSW whom the drawing has been prepared for.

tbBranchName

5 Section name The Section name within TfNSW whom the drawing has been prepared for.

tbSectionName

6 Department name The Department name within TfNSW whom the drawing has been prepared for.

tbDepartmentName

7 Drawn by (Name) Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.

tbDrwnName

8 Drawn date Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details

tbDrwnDate

9 Designed by (Name) Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details

tbDsnName

10 Designed date Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.

tbDsnDate

11 Drawing checked by (Name)

Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.

tbDrgChkName

12 Drawing checked date


tbDrgChkDate

13 Design checked by (Name)


tbDsnChkName

14 Design checked date Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.

tbDsnChkDate

15 Project/Design Manager (Name)

The full name of the contractor’s Project or Design Manager.

tbProjDsnMngrName

16 Project/Design Manager date

Date of sign-off by the contractor’s Project or Design Manager.

tbProjDsnMngrDate

17 Approved by (Name) Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.

tbApprName

18 Approved date Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.

tbApprDate







6.3.1.3. Amendment box

The amendment box records the details of all amendments made to a drawing. The amendment details include the Design company’s amendment level and description along with the initials of the designer, verifier and the approver.

The ‘REV’ column records the Design company revision levels of the drawing. Refer to Section 3.3.5 for details.

A brief but informative description of the changes made to the drawing shall be added to the 'DESCRIPTION' column. The initials of the designer, verifier and approver shall be placed in the amendment box for each drawing issue.

Where possible, at least three letters for the initials are required to minimise the possibility of misidentification of approvers with common first initial and last initial.

The oldest amendment entries shall be displayed at the bottom of the list. The amendment history items should be removed only when all available lines have been used. In this case, the oldest amendment information is removed, and the rest of the entries are moved down to create room for the new amendment at the top of the list.

Figure 13 shows the different fields in the amendment box.

Figure 13: Amendment box on a typical TfNSW Digital Engineering drawing sheet

Table 36 provides the details of these fields at publication time of this Standard. All data entry fields in the amendment box are included as attributes. Refer to DMS-FT-562 CAD Schema and Specification for the current specification and further details.

Table 36: Amendment box – Digital Engineering attributes description


1 Scale Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.

tbScale

2 Design lot code Option field used by the contractor to support delivery phase, leave blank if not required.

tbDesignLotCode

3 Co-ordinate system

Identify the survey coordinate system being used for the project, including first Geocentric Datum of Australia (GDA) information and Map Grid of Australia (MGA).

tbCoordSys








4 Height datum Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.

tbHghtDatum

5 Amendment level Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.

tbAEORevNo

6 Amendment description


tbAMDDesc

7 Amendment designer initial and date


tbAMDDsgnSD

8 Amendment verifier initial and date


tbAMDVerSD

9 Amendment approver initial

The initials of the person who approved the amendment.

tbAMDApprSign

10 Amendment approver date

The amendment date the drawing is approved and signed.

tbAMDApprDate

6.3.1.4. Drawing frame details

The drawing frame details provide additional information relevant to the production of each drawing sheet from the model and to be submitted at project milestones. The details of each required attribute are shown in Table 37 at publication time of this Standard. Refer to DMS-FT-562 CAD Schema and Specification for current specification and further details.

Table 37: Drawing frame details – Digital Engineering attributes description


1 Security Classification Description

As per 'NSW Government Information Classification, Labelling and Handling Guidelines'. Refer to FT-549 DE title block for position.

TfNSW_SecurityClassificationDesc

2 Model reference

Reference to model document number(s) and revision(s), for cases where it is important to display which model(s) or revisions(s) are showing on the drawing. Refer to FT-549 DE title block for position.

tbModelReference

3 Suitability description

The Suitability Description is the description of the State and Suitability Code assigned to a document when sharing. The Suitability Description value is governed by TfNSW.

TfNSW_SuitabilityDesc

6.3.1.5. Cover sheet details

The cover sheet details provide the minimum project information relevant to each of the CAD deliverables being submitted at project milestones. The typical details of the fields,at publication time of this Standard, should include and not limited to the following shown in Table 28. Refer to DMS-FT-562 CAD Schema and Specification for the current specification and further details.







Table 38: Cover sheet details – Digital Engineering attributes description


1 Program name The Program Name. TfNSW_ProgramName

2 Work package code (Construction)

A unique code generated for a Construction Work Package created for the project at the Construction stage. The Construction Work Package Codes are generated within the PDBB.

TfNSW_WPConstructionCode

3 Work package name (Construction)

The Work Package Name (Construction) field is to be populated for Work Packages relating to Construction packages of work.

TfNSW_WPConstructionName

4 Work package code (Design)

A unique code generated for a Design Work Package created for the project at the Design stage. The Design Work Package Codes are generated within the PDBB.

TfNSW_WPDesignCode

5 Work package name (Design)

The Work Package Name (Design) field is to be populated for Work Packages relating to Design packages of work.

TfNSW_WPDesignName

6.3.2. CAD layer naming

All information (geometric or non-geometric) related to an object or asset type shall be named with a common language and structure as required by the project in the format below and as shown in Table 39.

CAD layer names = [Discipline] + [Classification] + [Presentation] + [Description]

Table 39: CAD Layer naming examples

Discipline Code

Uniclass 2015 Classification Code

Presentation Code

Layer Description

AR - Ss_25_10_20 - M _ CurtainWallSystem

CV - EF_20_50 - M _ BridgeAbutment

GN - Zz_20_10_90 - T _ Text1.0mm

6.3.2.1. Discipline

For 2D CAD artefacts, mapping layers are required to meet with DE-defined disciplines as denoted in the project CAD Schema and Specification (based on DMS-FT-562) and follow the principles established in Section 4.2.3 under Discipline classification and referencing.

6.3.2.2. Classification

All asset information shall be classified based on the nominated classification system as denoted in Section 4.2. The Classification field shall form part of the layer names as required at the Integrated Design Review stage, refer to Table 40. The Uniclass 2015 table for CAD







(Zz) is applicable to drawing-related items at all stages. This may vary from one Integrated Design Review to another.

Table 40: Asset Classification Requirements for CAD layers

TRACC Integrated Design Review Ss

EF

3 Concept Design Development Ss_xx

or

EF_xx

4 Systems Breakdown Review Ss_xx_xx EF_xx_xx

Preliminary Design Review Ss_xx_xx_xx EF_xx_xx

Detailed Design Review Ss_xx_xx_xx_xx EF_xx_xx

Final Design Review

5 Final Specification Review Ss_xx_xx_xx_xx EF_xx_xx

As Built Review

6.3.2.3. Presentation

The Presentation code shall be from Section 12.2 of BS1192:2007 and as per Table 41. This ensures that the information can still be re-used for a variety of presentation purposes without conflicting with re-use of information.

Table 41: Standard Codes for Presentation (PAS 1192: 2007)

Ref Code Description

1 D Dimensioning

2 H Hatching and Shading

3 M Model related elements

4 P Plot/paper related elements

5 T Text

6 X Existing

6.3.2.4. Description

The description should give a clear and concise explanation of the Uniclass 2015 code, in particular when it is necessary to distinguish between different types of configurations of items that fall under the same classification code. Further guidance on one or more options of conventions for appending the description will be defined in the DE Framework Supporting Documents.

For example, considering a detailed breakdown of concrete wall types listed in logical groupings using DE conventions:

ST-Ss_25_11_16-M_ConcreteWallCore

ST-Ss_25_11_16-M_ConcreteWallExternal

ST-Ss_25_11_16-M_ConcreteWallInternal







6.3.3. Composite models

Where a project is required to deliver a ‘composite model’ or similar, compliance with this DES enables a composite model to be in the format of a Federated Model in the project deliverables.

The Federated Model should be submitted in the format specified in Section 6.4 showing the extent of the design. The files should not be password protected or have an expiry date set and all native models shall be included as part of the submission in their original file format.


Existing data and information are to be reviewed for relevancy to the project. Where existing CAD information is to be utilised as a part of the project, this data is to be validated and verified in accordance with this DES, if not already compliant.

6.3.5. Validation

All 2D CAD deliverables produced during the project will be validated at key milestones of the project, in alignment with the MIDP, MPDT, ECM Schema and Specification, CAD Schema and specification, and CAD layering naming table, as documented within the Project DEXP and the project CAD requirements.


All 2D CAD deliverables must be submitted in the following formats with each of the native authoring software version agreed with TfNSW and documented in the Project DEXP.

1. Drawing image file

.pdf format (singular)

.pdf format (combined file adopting a 999999 serial number in the document number)

Vector

2. Drawing CAD file

Either. dgn or .dwg formats

Unbound

One drawing sheet per drawing number as a drawing file output, multiple drawings in the one file will not be accepted unless agreed with TfNSW DE manager and VPR (where applicable)

3. Zipped drawing with reference files

.zip format

Contains .dgn or .dwg drawing file plus all relevant reference files

All reference files to be linked via relative paths







4. The drawing authoring software’s native file format, if this is something other than .dgn or .dwg

Submission formats to be agreed appropriate to the software used For example: If drawings are produced in Revit, the .rvt file which forms part of a milestone submission must include the sheets.

6.3.6.1. Metadata spreadsheet

The DE drawing titleblock (refer to DMS-FT-549) includes metadata fields that support the data exchange for the ECM and TfNSW document repositories.

A metadata spreadsheet must be provided with each drawing submission, the spreadsheet can be generated from the nominated CDE or ECM tool, or extracted from the drawing to include the attribute names and values listed in Table 33, Table 35, Table 36 and Table 37 at a minimum.

For Rail projects, T MU MD 00006 F1 Metadata Spreadsheet for Engineering Drawings must be used by the Contractor for providing titleblock information. Completion of the metadata spreadsheet links all the field data entries exported from BIM Models with VPR metadata. Refer to T MU MD 00006 F1 Metadata Spreadsheet for Engineering Drawings for further details.







6.4. BIM deliverables

The BIM deliverables are required to be submitted for appropriate Integrated Design Reviews. The submission requirement for each Integrated Design Review is shown in Table 42.

Unless otherwise stated in the contract, each submission shall include:

String Model(s)

Individual discipline BIM Model(s)

Individual IFC Models

Federated Model(s)

A clash detection report

A Model Validation Certificate (DMS-FT-556)

A Contractor facilitated model review workshop.

These requirements are further described in the following sections.

Table 42: BIM Model Submissions


Model Type Description/Purpose Submission Requirement

3 CDD Concept Design Model

Initiation of communicating design intent for a project in the form of BIM Models.

The frequency of model submissions during the concept design phase is specified in the project contract.

ECM tool

4 SBR NA - -

PDR Preliminary Design Model

Models used for capturing Design Intent and assist in high level decision making.

The frequency of model submissions during the preliminary design phase is specified in the project contract.

ECM tool

DDR Detailed Design Model

Models used to assist with both decision-making processes and design coordination.

The frequency of model submissions during the detailed design phase is specified in the project contract.

ECM tool








Model Type Description/Purpose Submission Requirement

FDR Final Design Model

Approved for Construction Model

The Final Design Model is the final TfNSW agreed model produced by the project, submitted to the Sponsor.

When the Final Design Model is agreed with the Sponsor, it is marked ‘Approved For Construction’. The BIM Model(s)/ Federated Model must be submitted to TfNSW before construction can commence.

ECM tool

5 FSR Approved for Construction Model

Accepted For Construction model updated to reflect the changes of the review, unless otherwise stated in the contract.

ECM tool

Construction Model

Changes are captured progressively throughout construction and updated in the BIM Model as required by the contract.

ECM tool

ABR As-Built Model The As-Built Model is a model (or models) that capture exact conditions at the completion of construction.

This model may have to compliment 3D laser scan data to verify the installation of already constructed work and record the as built position.

ECM tool

O&M Model The O&M Model is a model that represents a record of what was constructed, installed, and tested prior to handover. The O&M Model may be used for operations and maintenance.

The O&M Model will contain accurate attribute data for maintainable equipment and systems used asset management, as included in the Handover Asset Register.

The O&M Model is updated based on information provided by the relevant Contractor (eg digital mark-ups, photography, or laser scans).

ECM tool

6.4.1. BIM process requirements

Terminology used in the production of BIM Models is summarised in Table 43.

Table 43: Building Information Modelling terminology







Ref Term Source Description

1 Level of Detail (LoD)

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

2 Level of Information (LoI)

PAS 1192.2 Level of Information is the amount of non-geometrical (non-graphical) data embedded within an Information Model or 3D model.

3 Level of Definition

PAS 1192.2 Level of Detail (LoD) together with Level of Information (LoI) is referred to collectively as Level of Definition.

4 Level of Development (LOD)

BIM Forum (2020) Level of Development (LOD) Specification

Used for reference only.

The Contractor is responsible for managing the overall cross discipline BIM collaboration process. To achieve this, each design discipline must model to a minimum Level of Definition sufficient to enable an appropriate level of coordination to take place, as per Table 44. The coordination process shall be developed along with the following principles:

• All spatial information must adopt the same standard datum as detailed in Section 6.2. A local datum can be adopted to accommodate the limitations of some software packages, however all spatial information must be projected from the local datum to the standard datum adopted. Coordinates and setting out details shall be coordinated across the project, using a master project control set out file when using a local datum.

• Information from other contributors shall be referenced directly in the Federated Model during design for clash avoidance.

• All BIM objects must be classified as per the phased requirements specified in Table 47 and Table 48.

• BIM Models must be managed and maintained, removing any superfluous or superseded data before exchanged in the file formats identified in Section 6.4.7.

• Regular model coordination sessions are to be implemented appropriate to the project scope, as specified in the Project DEXP.

The federated GIS and/or BIM environment shall be used as the focus for resolution and progress of design using a virtual design/ construction review process.

In addition to the above principles, the Contractor is required to adhere to the following requirements for the submission of BIM Models and related information:

• All Contractors must submit BIM Models to TfNSW using the ECM tool, for TfNSW review and comment. Submission must be in accordance with Table 42 and as per project milestones documented in the Project DEXP.







• All Contractors must submit BIM Models in accordance with the Level of Definition requirements outlined in Table 44 unless specific project requirements have been agreed in the Project DEXP.

• 2D drawing deliverables must be derived from the native or BIM Model, and created in accordance with the requirements outlined in Section 6.3.

• Any other supporting information which is relevant to the BIM Model must be included in the submission to the ECM.

6.4.1.1. Review of existing data

All or any existing data must be reviewed for accuracy and degree of useability and relevance to the project. Where existing data is to be re-used as part of a new deliverable, this data is to be classified in accordance with this DES, if not already compliant.

Existing site information and/or legacy data available to the project must be verified against the existing conditions for any discrepancies and assessment of accuracy. Depending on the outcomes, a decision will be made on the reliance of any existing BIM Models for further use on the project.

All major discrepancies with existing site information must be discussed and a resolution agreed with the DE Manager before being used on TfNSW projects.

6.4.2. BIM Model requirements

Requirements for geometrical information (LoD) and the non-geometrical information (LoI) inclusion in the individual discipline BIM Model(s) and Federated Model is specified in the following sections.

TfNSW and the Contractor shall agree and specify any project specific requirements, departing from the baseline requirements specified below. The Level of Definition for all technical disciplines and asset types for each project phase must be documented in the Project Model Production Delivery Table (based on DMS-FT-534 Model Production Delivery Table (MPDT) Template).

6.4.2.1. Levels of Detail (LoD)

Refer to Table 44 for examples and descriptions of LoD for each project phase. Baseline LoD requirements are given for each technical discipline and phase in Table 45. Refer to Appendix B for further examples.




DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207


Table 44: Levels of Detail examples and descriptions


CDD SBR, PDR DDR, FDR, FSR, ABR

If required by the project contract

LoD (PAS 1192.2)

2 3 4

- 5 6

LOD (BIM Forum)

LOD 100 LOD 200 LOD 300

LOD 350 LOD 400 LOD 500

Geometric Representation (Building Specific) (BIM Forum)

Geometric Representation (Infrastructure Specific) (PAS 1192_2)

Description (PAS 1192_2)

(**BIM Forum)

Models which communicate the initial response to the brief, aesthetic intent and outline performance requirements. The model can be used for early design development, analysis and co-ordination. Model content is not fixed and may be subject to further design development.

A dimensionally correct and co-ordinated model which communicates the response to the brief, aesthetic intent and some performance information that can be used for analysis, and early Contractor engagement.

A dimensionally correct and coordinated model that can be used to verify compliance with regulatory requirements. The model can be used as the start point for the incorporation of specialist Contractor design models and can include co-ordination, sequencing estimating purposes.

**The Model Element is graphically represented within the Model as a specific system, object, or assembly in terms of quantity, size, shape, location, orientation, and interfaces with other building systems. Non-graphic information may also be attached to the Model Element.

An accurate model of the asset before and during construction incorporating co-ordinated specialist subcontract design models and associated model attributes. The model can be used for sequencing of installation and capture of as installed information.

An accurate record of the asset as constructed at handover, including all information required for operation and maintenance.







Table 45: TfNSW Baseline Levels of Detail by Technical Discipline

Model Type

Concept

Desig

n

Mode

l

Pre

limin

ary

Desig

n M

ode

l

Deta

iled

Desig

n M

ode

l

Appro

ve

d F

or

Constr

uction

Mode

l

Constr

uction

Mode

l

As-B

uilt

Mod

el

O&

M M

ode

l

Integrated Design

Review CDD PDR DDR/FDR FSR ABR

Discipline Code

LO

D

Lo

D

LO

D

Lo

D

LO

D

Lo

D

LO

D

Lo

D

LO

D

Lo

D

LO

D

Lo

D

LO

D

Lo

D

Architectural AR 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Communication CO 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Civil CV 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Electrical EL 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Fire FE 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Fleet Systems & Equipment

FL 100 2 200 3 300 4 300 4 300 4 300 4 300 4

General GN 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Hydraulic HY 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Mechanical ME 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Signalling & Control

SG 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Structural (no reinforcing)

ST 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Structural (with reinforcing)

ST 100 2 200 3 350 - 350 - 350 - 350 - 350 -

Technology TE 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Utilities UT 100 2 200 3 300 4 300 4 300 4 300 4 300 4

Sub-Discipline*

Geotech GE 100 2 200 3 200 3 200 3 200 3 200 3 200 3

Landscaping LA 100 2 200 3 200 3 200 3 200 3 200 3 200 3

Temporary Works TW 100 2 200 3 200 3 200 3 200 3 200 3 200 3

*where the requirement differs from the parent discipline

6.4.2.2. Levels of Information (LoI)

The contractor must ensure the BIM Model(s) is populated with the model properties requirements following, noting the required attributes to comply with the TfNSW IFC properties and property sets, as defined in the BIM Schema and Specification (DMS-FT-516). The model properties must be populated with the individual elements contained within the BIM Model(s) as object attributes (metadata).







6.4.2.3. Model properties requirements

To comply with TfNSW data requirements, the Contractor must comply with the property requirements specified in the Project DEXP and DMS-FT-516 BIM Schema and Specification. Refer to Table 46 for the FDR stage property requirements, at the time of publication of this Standard. Refer to the latest version of DMS-FT-516 BIM Schema and Specification for current requirements.

TfNSW may include project-specific requirements in the contract. The contractor may also elect to include additional attributes within the BIM Model to aid in delivery. These additional attributes should be included within a discipline or subdiscipline IFC Property Set they belong to, prefixed with TfNSW ie TfNSW_Utilities or TfNSW_Temporary_Works.

Table 46: Model Properties Requirements

Ref Model or Object

Property Data Dictionary Field Name

FDR Inclusion

IFC Property Set

Attribute Name

1 Model Project And Contract Name Mandatory TfNSW_Project TfNSW_ProjectAndContra

ctName

2 Model Project Contract Code Mandatory TfNSW_Project tbProjectContractCode

3 Model AEO Engineering Company Code Mandatory TfNSW_Project tbAEOSuppCode

4 Model AEO Engineering Company Name Mandatory TfNSW_Project tbAEOSuppName

5 Model Design Company Code Conditional TfNSW_Project tbDesignCompCode

6 Model Design Company Name Conditional TfNSW_Project tbDesignCompName

7 Model Co-ordinate System Mandatory TfNSW_Project tbCoordSys

8 Model Project Milestone Description Mandatory TfNSW_Project TfNSW_ProjectMilestoneD

esc

9 Model State Description Mandatory TfNSW_Project TfNSW_StateDesc

10 Model Suitability Description Mandatory TfNSW_Project TfNSW_SuitabilityDesc

11 Model Document Number Mandatory TfNSW_Project TfNSW_DocumentNo

12 Model Document Title Mandatory TfNSW_Project TfNSW_DocumentTitle

13 Model Discipline Code Mandatory TfNSW_Project tbAEODisciplineCode

14 Model Sub-discipline Code Conditional TfNSW_Project tbAEOSubDiscCode

15 Object TfNSW Asset Location ID Optional TfNSW_Location TfNSW_AssetLocationID

16 Object TfNSW Parent Asset Location ID Conditional TfNSW_Location TfNSW_ParentAssetLocati

onID

17 Object Project Asset Location ID Mandatory TfNSW_Location TfNSW_ProjectAssetLocati

onID

18 Object Parent Project Asset Location ID Conditional TfNSW_Location TfNSW_ParentProjectAsse

tLocationID

19 Object Asset Location Code Mandatory TfNSW_Location TfNSW_AssetLocationCod

e

20 Object Parent Asset Location Code Conditional TfNSW_Location TfNSW_ParentAssetLocati

onCode

21 Object Asset Location Description Mandatory TfNSW_Location TfNSW_AssetLocationDes

c

22 Object Uniclass 2015 Asset Location Code Mandatory TfNSW_Location TfNSW_UniclassAssetLoc

ationCode

23 Object Uniclass 2015 Asset Location Title Mandatory TfNSW_Location TfNSW_UniclassAssetLoc

ationTitle

24 Object Work Zone Code Optional TfNSW_Location TfNSW_WorkZoneCode

25 Object Work Zone Name Optional TfNSW_Location TfNSW_WorkZoneName

26 Object Uniclass 2015 Asset Location Code (Complex)

Optional TfNSW_Location Uniclass_CoCode

27 Object Uniclass 2015 Asset Location Title (Complex)

Optional TfNSW_Location Uniclass_CoTitle

28 Object Uniclass 2015 Asset Location Code (Entity)

Optional TfNSW_Location Uniclass_EnCode

29 Object Uniclass 2015 Asset Location Title (Entity)

Optional TfNSW_Location Uniclass_EnTitle







Ref Model or Object

Property Data Dictionary Field Name

FDR Inclusion

IFC Property Set

Attribute Name

30 Object Uniclass 2015 Asset Location Code (Space)

Optional TfNSW_Location Uniclass_SLCode

31 Object Uniclass 2015 Asset Location Title (Space)

Optional TfNSW_Location Uniclass_SLTitle

32 Object TfNSW Asset ID Optional TfNSW_Asset TfNSW_AssetID

33 Object TfNSW Parent Asset ID Conditional TfNSW_Asset TfNSW_ParentAssetID

34 Object Project Asset ID Mandatory TfNSW_Asset TfNSW_ProjectAssetID

35 Object Parent Project Asset ID Conditional TfNSW_Asset TfNSW_ParentProjectAsse

tID

36 Object Asset Data Standard Mandatory TfNSW_Asset TfNSW_AssetDataStandar

d

37 Object Asset Type Code Mandatory TfNSW_Asset TfNSW_AssetTypeCode

38 Object Asset Instance Mandatory TfNSW_Asset TfNSW_AssetInstance

39 Object Asset Code Mandatory TfNSW_Asset TfNSW_AssetCode

40 Object Parent Asset Code Conditional TfNSW_Asset TfNSW_ParentAssetCode

41 Object Asset Description Mandatory TfNSW_Asset TfNSW_AssetDescription

42 Object Asset Label Mandatory TfNSW_Asset TfNSW_AssetLabel

43 Object Uniclass 2015 Asset Code Mandatory TfNSW_Asset TfNSW_UniclassAssetCod

e

44 Object Uniclass 2015 Asset Title Mandatory TfNSW_Asset TfNSW_UniclassAssetTitle

45 Object Asset Type Configuration Code Optional TfNSW_Asset TfNSW_AssetTypeConfig

Code

46 Object Asset Type Configuration Description Optional TfNSW_Asset TfNSW_AssetTypeConfig

Desc

47 Object Discipline Code (Object) Mandatory TfNSW_Asset TfNSW_DisciplineCode

48 Object Sub-discipline Code (Object) Conditional TfNSW_Asset TfNSW_SubDisciplineCod

e

49 Object Work Package Code (Design) Mandatory TfNSW_Asset TfNSW_WPDesignCode

50 Object Work Package Code (Supply) Optional TfNSW_Asset TfNSW_WPSupplyCode

51 Object Work Package Code (Construction) Optional TfNSW_Asset TfNSW_WPConstructionC

ode

52 Object Work Package Code (Commissioning) Optional TfNSW_Asset TfNSW_WPCommissionin

gCode

53 Object Asset Status Code Mandatory TfNSW_Asset TfNSW_AssetStatusCode

54 Object Asset Owner Organisation Name Mandatory TfNSW_Asset TfNSW_AssetOwnerOrgN

ame

55 Object Asset Operator Organisation Name Optional TfNSW_Asset TfNSW_AssetOperatorOrg

Name

56 Object Asset Maintainer Organisation Name Optional TfNSW_Asset TfNSW_AssetMaintainerOr

gName

57 Object Start km Mandatory TfNSW_Asset TfNSW_StartKm

58 Object End km Conditional TfNSW_Asset TfNSW_EndKm

59 Object GPS Coordinates Conditional TfNSW_Asset TfNSW_GPSCoordinates

60 Object Uniclass 2015 Asset Code (Element Function)

Optional TfNSW_Asset Uniclass_EFCode

61 Object Uniclass 2015 Asset Title (Element Function)

Optional TfNSW_Asset Uniclass_EFTitle

62 Object Uniclass 2015 Asset Code (System) Optional TfNSW_Asset Uniclass_SsCode

63 Object Uniclass 2015 Asset Title (System) Optional TfNSW_Asset Uniclass_SsTitle

64 Object Uniclass 2015 Asset Code (Product) Optional TfNSW_Asset Uniclass_PrCode

65 Object Uniclass 2015 Asset Title (Product) Optional TfNSW_Asset Uniclass_PrTitle







6.4.2.4. Model classification requirements

The level of granularity required for classification of model objects develops progressively over the life of the project, as presented in Table 47 and Table 48.




and

En_xx

and / or

SL_xx

4 Systems Breakdown Review Co_xx_xx En_xx SL_xx



Final Design Review


As Built Review




and

Ss_xx

and

As required




Final Design Review


As Built Review

TfNSW requires that, minimally, one location classification and one asset classification must be attributed to each modelled object, to the System level for CDD and SBR and to the Product level from PDR to ABR.

6.4.3. Utility information

6.4.3.1. Utility validations

The contractor must review, update and validate any existing utility information provided to them, including geometrical and non-geometrical information using DBYD, surveyed ground features, electromagnetic survey, potholing and other relevant information to ascertain the quality of the utility information provided for use during the design. The contractor must advise TfNSW of any additional utility survey required to complete the design.







6.4.3.2. Utility model

In addition to Section 6.4.2.1, the Contractor must create a BIM Model of all existing and proposed subsurface and surface utility model based on the survey, Dial Before You Dig (DBYD) and other relevant information. The utility model must be geometrically accurate in terms of quantity, size, shape, location and orientation, and to the Level of Definition defined within this specification.

6.4.3.3. Utility attributes & accuracy

The Contractor must apply attributes to all existing and proposed subsurface and surface utilities including owner, type, size, status, material, configuration, quality level etc as per the DMS-FT-516 Utility Schema and Specification and AS 5488.2:2019 Part 2: Subsurface Utility Engineering Requirements. These attributes should supplement the LoI requirements in Section 6.4.2.2 and must be included in the Federated Model for ease of reference and to support clash detection analysis and 4D construction simulation (if applicable).

The utility attributes must be included in an IFC Property Set named TfNSW_Utilities with the attribute names and values aligned with the Utility Schema and Specification.

Where the quality level of a utility is unknown then it must be labelled Quality Level D. If there is no accompanying metadata with the utility information, then Quality Level “D” must be assumed for that utility. Refer to Appendix A of AS 5488.1:2019 Part 1: Subsurface Utility Information for the quality level definitions. Quality Level D information should not be draped to the surface and assumed or typical depths applied to create the 3D model.

6.4.3.4. Utility Investigation Information

The Contractor must spatially provide utility investigation information in the Federated Model and identified by a symbol or flag and labelled with the utility pothole or trench reference number and its type as per the Utility Schema and Specification (ie “C” for Communications, “E” for electricity, “W” for Water etc).

6.4.4. Model federation

A Federated Model is a compilation of individual models combined into one single application for coordination and interrogation. Refer to the terms and definitions outlined in DMS-ST-202 TfNSW DE Standard, Part 1 – Concepts and principles for details. BS1192 refers to the Federated Model as “Combined”.

It is the responsibility of the Contractor to compile all individual discipline BIM Models to create the Federated Model and ensure consistent processes for model sharing and coordination are in place. Contractors must address the following requirements:

• All BIM Model authoring software and procedures must be defined, implemented and documented within the Project DEXP.

• All BIM Model reviewing software and procedures must be defined, implemented and documented in the Project DEXP.

• A model coordination strategy must be implemented by the Contractor and documented within the Project DEXP.







• Information exchange procedures must be implemented by the Contractor and documented in the Project DEXP.

• A procedure for recording and communicating changes to BIM Models must be implemented by the Contractor and documented in the Project DEXP.

6.4.5. Clash detection

The Contractor must use the Federated Model to complete clash detection and to ensure the model is clash free. The contractor is required to document their rules based clash detection procedure to be adopted by the project in the Project DEXP for agreement with TfNSW, including how clashes will be managed and prioritised.

The contractor must provide a clash matrix as part of the Project DEXP that includes existing, temporary and design elements to be clash checked and assign priority based on time, cost and impact to resolve the clash. Refer to Section 4 and Appendix D of AS 5488.2:2019 Part 2: Subsurface Utility Engineering Requirements for further guidance on the clash detection process and an example clash matrix for utilities, the same principles can be applied to other elements within the model(s).

Clash detection must consider interference clashes and clearances between objects to meet standard authority requirements and construction methodology, including temporary works, excavation zone of influence and space allocation to safely construct the works. Adopting a hard clashes procedure across the project is not sufficient to ensure the model(s) are clash free and fully coordinated.

The rules based clash detection process, consistent with the agreed clash matrix must be included as part of the Federated Model, with a clash detection report exported from the automated clash detection platform and included with each submission of the Federated Model. All identified clashes should be numbered, with similar clashes within the model(s) grouped, with commentary added to identify how each clash should be addressed and assigned an owner to resolve, clashes that are not ‘real’ must be resolved before submitting the clash report at each submission.

6.4.6. Model reviewing and validation

All BIM data produced shall be validated at key milestones of the project. Data within models must be audited against the information contained within the Project Model Production Delivery Table (MPDT) and the requirements of the BIM Schema and Specification (DMS-FT-516). Any specific model review workflows and processes must be documented in the Project DEXP, in particular the following:

• Contractor’s internal model review process

• Contractor’s internal data validation process

A Model Validation Certificate (DMS-FT-556) must be included with model submissions and provided as confirmation that the Contractor has completed an appropriate quality assurance review of the model prior to submission, including confirmation that:

• The BIM Models have the required properties and data as summarised in the Model Property Check (DMS-FT-454).

• The Level of Definition for model elements/disciplines is as agreed with TfNSW







• Federation of BIM Models has been appropriately achieved

• Clash detection has been completed

• The models are coordinated

• The model is appropriate for use during the next phase of the project and/or asset lifecycle

• The model data is consistent with the Asset Register data (refer to Section 6.9.1)

• The comments in the project comments register have been addressed

A strategy for quality assurance is to be documented in the Project DEXP and adopted by all collaborating parties.

6.4.6.1. Timing of model reviews and workshops

The timing of model reviews must be documented in the Project DEXP, and taking into consideration:

• Critical project milestones

• Contractor internal processes

• Key interfaces or other points raised by TfNSW

Model review workshops are to be appropriately scheduled to provide adequate collaboration and review between modelling parties.

6.4.6.2. Addressing design comments

All Contractors must produce design review comments which are placed into a comment register in accordance with TfNSW requirements (refer to the project contract). The file format of the register, its location, and structuring of design comments will be at the discretion of TfNSW and agreed with TfNSW DE Manager before being used on TfNSW projects.


This section defines mandatory file format requirements. Refer to the Project DEXP for specific BIM Model file formats required by TfNSW.

• All BIM Models must be submitted to TfNSW in their original native file format.

• All BIM Models must be submitted as a Navisworks Cache (NWC) (individually), Navisworks Document (NWD) (federated), or other collaboration file format agreed in the Project DEXP.

• All BIM Models must be submitted in the Industry Foundation Class (IFC) format 2x3, as individual files to form part of the federated file. These submissions will be required at key project milestones. Newer versions of IFC format may be submitted if approved by the TfNSW DE Manager.

• All BIM Models (IFC and native) and Federated Model(s) must include the model property requirements, as per section 6.4.2.3.







• String-based models must be submitted in a LandXML format 1.2 or higher to retain true geometry.

• The maximum file-size limit must not exceed 500MB for the individual BIM Models, though the software, file format and contents should be taken into account and others (for example point clouds) may be larger. Large files should be discussed with the TfNSW DE Manager and monitored for performance. If file size is deemed to be diminishing project performance in any way, the issue must be addressed by subdividing the models or purging unnecessary contents.

BIM Model files and any derived information including 2D drawings, produced for TfNSW must be identified using the file naming convention described in Section 3.3 for upload to the ECM tool.







6.5. Visualisation

TfNSW has standardised visualisation types to drive consistency of the outputs that are delivered and ensure that all information produced or used in the creation of the visualisation is also handed over for reuse.

6.5.1. Visualisation requirements

The type of visualisation specified by the project and the requirements for visualisation deliverables are determined based on the project’s scope, DE strategy and opportunities for reuse.

The Visualisation Requirements Guide (DMS-SD-130) may be referred to by the TfNSW project team to assist with the specification of visualisation and utilisation of DE methodology in the Contract and Project DEXP. Visualisation types include but are not limited to:

Proposal communication

Photorealistic artistic impression

Photorealistic photomontage.

The Contract and Project DEXP is to define any project specific requirements for visualisation deliverables. Unless specified otherwise in the Contract or Project DEXP, visualisation submissions must meet the deliverable requirements listed in Table 49.

Table 49: Visualisation deliverables

Ref Required deliverable

Description

1 Visualisation deliverable

The Contractor must provide the visualisation deliverable in a digital file format appropriate to its intended usage and audience, as specified in the Contract and/or Project DEXP.

2 Visualisation software native file

The native file formats for the specialist visualisation software package or packages that have been used in the process of creating the visualisations must be provided to TfNSW as part of the submitted deliverable.

3 Visualisation software open source file

An open source file produced from the visualisation software that will include the information contained within the native file, including; 3D geometry; colour, material and texture maps, camera locations and settings, lighting and relative positioning. The FBX file format, although classed as a proprietary format is seen as an industry exchange solution and must be provided to TfNSW as part of the submitted deliverable.

4 Post-production software file

Should any post-production work be undertaken as a part of the visualisation process, the native files for these software applications must be provided to TfNSW as part of the submitted deliverable.

5 Supporting content files

Files that have been created as an output from the BIM authoring or visualisation software and then further enhanced or compressed in post-production software must be provided to TfNSW as part of the submitted deliverable. An example of this type of content is image files rendered out of a visualisation package that would then be ‘stitched’ together to form an output animation.







Ref Required deliverable

Description

6 Material map Where material texture files are used in the visualisation process these must be provided to TfNSW as part of the submitted deliverable. This is appropriate for where the materials are not embedded in the native authoring or visualisation software.

7 Additional artefacts

Specialist plugins may be used to add additional content into the visualisation for realism purposes such as people, vegetation and vehicles. Where licencing allows this content must be provided to TfNSW as part of the submitted deliverable.


The classification of visualisation data is linked to the intended use as well as the primary domain (rail, roads, maritime, etc. assets) of the project. Appropriate classification of visualisation data is key to the ongoing effective use of the visualisation deliverables.

Where BIM Models are utilised as the foundation of the visualisation, existing classification data within the model, as described in Section 6.4, is to be maintained.

Additional classification requirements are to be specified in the Project DEXP, dependent on the intended usage and reuse requirements.


Existing visualisation data and information provided is to be reviewed for relevancy to the project. Where existing visualisation information is to be utilised as a part of the project, this data is to be validated and verified in accordance with this DES, if not already compliant. Projects must also confirm relevancy and applicability of existing visualisation data with the TfNSW project team.

6.5.4. Validation

All visualisation deliverables produced during the project will be data validated at key milestones of the project. Validation will be for compliance with the relevant domain visualisation standards, alignment with the PDS, and compliance with the Contractor’s Project DEXP.


Visualisation deliverables are to be submitted to TfNSW in agreed formats and uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3.







6.6. GIS deliverables

TfNSW is standardising the approach to GIS systems and data management for delivery of projects to drive consistency of the outputs that are delivered and to ensure that all information produced or used in the creation of GIS outputs is handed over for reuse.

GIS has broad application in the Transport environment capable of supporting a range of activities that span the whole asset lifecycle, including:

Capturing existing conditions, including environmental conditions, demographic information, topology, etc.

Supporting site analysis and modelling, including environmental impact assessments, flood modelling, etc.

Enabling design integration, including embedding and evaluating 3D design models within existing condition GIS models

Supporting design reviews, for example through federation of 3D design models with other GIS datasets

Collating and reporting sensor data, for example providing live monitoring of air quality and noise levels through streaming of sensor data into a spatially enabled GIS model

Collating As Built models and information, which can then be made available to other Transport stakeholders, e.g. Operations & Maintenance.

Depending on specific project requirements Contractors may be required to provide GIS data deliverables as well as access to the Contractor’s GIS Application.

6.6.1. GIS requirements

The TfNSW QA Specification G75 – Geographic Information Systems (GIS), outlines the requirements for undertaking GIS work, including:

General requirements, such as identification of key GIS personnel and management of third-party software licencing arrangements

Technical requirements, which covers file formats, naming conventions, metadata and dataset level schema requirements. The specification also identifies requirements for cartographic products, data types, and the coordinate reference systems to be used for GIS

GIS application requirements, which is dependent on whether TfNSW requires access to a Contractor’s GIS application environment

Delivery requirements, including the need for a GIS Management Plan, as well as and requirements for meetings, reporting and submission of GIS deliverables.

QA Specification G75 is structured to align with other requirements of the DES and uses the DE templates DMS-FT-580 – GIS Schema and DMS-FT-581 – GIS Management Plan to facilitate alignment and enable integration with the DES. QA Specification G75 does not define the project scope of GIS activities and deliverables, and these must be defined and agreed with the relevant Contractor. Note that QA Specification G75 may also be used for non-DE GIS projects or activities.








GIS data, as a minimum, is to be structured and standardised in accordance with:

QA Specification G75 – Geographic Information Systems

DMS-FT-580 – GIS Schema.

Depending on the scope of the project the Contractor may also identify and adopt alignment with other elements of the PDS for the GIS work.

Complying with these requirements will assist project teams to ensure that:

All GIS information, where possible, represent geographically referenced locations, or x,y,z co-ordinates representative of real world positioning;

All GIS models having a relationship with the mapping grid or relative levels maintain the relationship between the CAD coordinate system, the map coordinate system and Australian Height Datum (AHD);

The GIS information contains sufficient metadata so that it can be assessed for its fitness for the intended purpose, or its appropriateness for another purpose; and

The GIS information is of a consistent format and can be combined with other GIS information stored in the Transport enterprise systems or the project GIS.

Compliance with G75 will facilitate spatial consistency between different project data sets across TfNSW.


Existing GIS data and information provided to, or sourced by, a project team is to be reviewed for relevancy to the project. Where existing GIS information is to be utilised as a part of the project, this data is to be validated and verified in accordance with this DES. Contractors must also confirm relevancy and applicability of existing GIS data with the TfNSW project team.

6.6.4. Validation

All GIS deliverables produced during the project will be data validated at key milestones of the project. Validation will be for compliance with:

The requirements of QA Specification G75 – Geographic Information System

The Contractor’s GIS Schema (DMS-FT-580), which is to be submitted with any formal GIS data submission (data drop) to TfNSW

The Contractor’s PDS

The Contractor’s GIS Management Plan (DMS-FT-581), when required

Other contract requirements.







6.6.5. GIS deliverable submissions

GIS deliverables are to be submitted to TfNSW in agreed formats and uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3.







6.7. Time deliverables

Requirements for time deliverables in this DES are currently limited to scheduling and 4D models. Additional requirements for time-related deliverables, such as detailed construction sequencing, are to be documented further in the contract or Project DEXP, as appropriate.

Scheduling (also known as programming) provides projects with the ability to plan, evaluate, communicate and better understand complex delivery methodologies prior to actual execution using a Gantt chart. Traditionally, the key challenges have been to ensure that;

(i) The full scope of the project is reflected in the schedule

(ii) The construction methodology logic and durations are accurate and can be practically delivered.

This DES requires that Contractor’s group activities in their schedules (Work Breakdown Structure (WBS)) using Work Package Codes. This approach improves traceability, ensures that time data can be easily associated with the BIM Model and that the construction methodology can be easily visualised in time-sequenced 3D models (also referred to as 4D). Project teams can effectively prototype the delivery of assets in a virtual environment first and, provide rapid feedback on design options as well as constructability. This is beneficial for planning work in a safe and systematic way that maximises efficiency on site.

DE enabled schedules also enhance the ability to quantify the impact of variations by ensuring alignment between the original baseline and current baseline schedules, as well as cost estimates and progress claims. This enables variations to be compared visually, dramatically reducing creation and assessment times. It also automates compliance with TfNSW’s Earned Value requirements and monthly project performance reporting.

Note: the DE scheduling requirements detailed in this DES must be read in conjunction with any project specific scheduling requirements within IP Scheduling Standard (DMS-ST-123) or specified in the Contract.

6.7.1. Project schedule deliverable requirements

For DE projects that require scheduling deliverables, all activities in the Contractor’s Primavera

P6 schedule (WBS) must be coded with the relevant Work Package Code provided by TfNSW

(refer section 4.2.4 for more information on Work Packages). The list of Work Packages will

be prepopulated in the project activity codes titled “Work Package Code” within the TfNSW

Primavera P6 environment. All activity codes are provided to the Contractor for reference via

the Project DEXP Template (based on DMS-FT-520 Scheduling Schema).

For this DES release, only Work Package Codes relating to Design, Supply, Construction, and

Commissioning activities must be assigned to all relevant P6 activities. This is to assist with

the automated association of schedule activities and BIM objects.

6.7.2. 4D model deliverable requirements

For DE projects that require 4D model deliverables, the Contractor must provide a time

sequenced model (4D) for each submission milestone or as requested by TfNSW. This may

be achieved through manual association or via attribution within the Primavera P6 schedule.







Both methods of working require alignment of the schedule data with the BIM model attributes,

utilising the project defined Work Packages.

The schedule activities and dates must integrate with the federated model in a software format

agreed with the TfNSW. The 4D model can be provided as either:

1. 4D GIS – compatible with TfNSW systems environment or viewable as a video.

2. 4D BIM – compatible with TfNSW CDE and provided in an agreed format, such as

Autodesk Navisworks, Bentley Navigator or Bentley Synchro.

The BIM objects within the 4D Model deliverables must comply with the BIM Deliverable

requirements in Section 6.4. The schedule or time related data must comply with the

requirements of this Section 6.7.

Refer to the project contract for details on whether 4D GIS or 4D BIM is required and the

frequency of submissions.

6.7.3. Existing data review

Existing time data and information are to be reviewed for relevancy to the project. Where existing time data, e.g. a Work Package hierarchy, is to be utilised as a part of the project, this data is to be classified in accordance with this DES, if not already compliant.

6.7.4. Validation

All scheduling deliverables produced and updated during the project will be data validated

monthly and/or at key milestones of the project from within the TfNSW Primavera P6

environment. Validation will be for compliance with the agreed Project Scheduling Schema

(based on DMS-FT-520), the agreed Contractor’s Project DEXP and other Contract

requirements.

All 4D Model deliverables will be validated upon submission for compliance with the scheduling

classification, BIM classification and other Contract requirements.

6.7.5. Time deliverable submissions

Scheduling deliverables and updates are to be provided to TfNSW in accordance with DMS-ST-123 IP Scheduling Standard. Any schedules required to be submitted as a pdf file for monthly reporting, etc. or 4D Model deliverables are to be uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3.







6.8. Cost deliverables

Cost deliverables are broken into three main categories; (i) cost estimates (including

contingency), (ii) contract payment schedules (i.e.; progress claims) and, (iii) variation

estimates (post-contract award). This DES only details the contract payment schedule

information requirements, with cost estimating and contingency coding structures to be

included in a future release.

Structuring cost estimate, progress claim and variation data consistently allow the project to

accurately track budget, forecast, and actual spend over the course of the project. It also allows

the project to compare different design and construction scenarios/options and variation

requests efficiently to inform value-based decisions.

By aligning the cost data structures with BIM and time data, cost estimates and progress claims

can be automatically associated with the BIM Model and schedule/program so that the impact

of progress can be easily visualised. The cost information can also enhance the TfNSW Earned

Value creation and simplify the monthly project performance reporting.

Separately, by standardising the way cost is structured across the business, TfNSW can

automate program and portfolio level cost reporting and finance. It also enables a consistent

cost benchmarking dataset to be built up for each location and asset type that can then be

reliably compared against future project estimates developed using the same data structure.

For all projects requiring Cost deliverables, the requirements in this DES must be read in

conjunction with any project specific cost requirements or amendments as specified in the

contract. This may include DMS-ST-173 Cost Estimating for Infrastructure and Place Projects

and T MU AM 01001 ST Life Cycle Costing.


6.8.1.1. Project cost estimates

The Cost Estimating requirements for DE is currently in development. All parties are required

to conform to existing TfNSW standards and requirements related to project costs, including

the requirement to align the Cost Breakdown Schedule with the WBS (refer to section 6.7).

Requirements may include DMS-ST-173 Cost Estimating for Infrastructure and Place Projects

and T MU AM 01001 ST Life Cycle Costing.

It is recommended that project costs are estimated and captured in a Cost Breakdown

Structure (CBS) that aligns Work Package Codes used for scheduling deliverables, and any

other suitable coding systems within the PDS. This integration of data coding will enable and

allow effective reuse, sharing and analysis of cost data.

6.8.1.2. Contract payment schedule

TfNSW may align the CBS within the tender/contract payment schedule to the Work Package

Codes in the PDS. Where aligned, this will enable cost information to be associated with

groups of BIM objects, schedule activities and agreed project milestones. Alignment of

schedule and costs will also enable automatic generation of earned value if required.







The contract payment schedule must be controlled to align with any changes to the Work

Package Codes agreed with TfNSW, as described in Section 4.2.4. This is required so that the

total cost of a Work Package at the end of the project can be easily quantified by TfNSW for

the purposes of asset capitalisation and benchmarking.

6.8.1.3. Project progress claims

All progress claims must be in the same format as the Contract Payment Schedule. It is

recommended that the Contractor’s internal CBS used for tracking costs is aligned with and

rolls up to the contract payment schedule structure provided by TfNSW to simplify reporting.

6.8.1.4. Variation costs

All variations must be estimated in the same CBS and Work Package Codes as the Contract

Payment Schedule. This is required so that the total cost of a Work Package at the end of the

project can be easily quantified by TfNSW for the purposes of asset capitalisation and

benchmarking.

6.8.2. 5D Model deliverables

For projects where 5D Cost deliverables are required refer to the specific cost requirements or

amendments as outlined in the project Contract.

The 5D Cost requirements for DE are currently under development. Pending this release, all

parties are required to conform to all cost and BIM requirements within this DES, along with all

existing TfNSW Standards and requirements related to project costs.


Existing cost data and information are to be reviewed for relevancy to the project. Where

existing cost and estimating data are to be utilised as part of the project, this data is to be

classified in accordance with this DES, if not already compliant.

6.8.4. Validation

Cost Estimates, Contract Payment Schedule code changes, progress claims, and variation

estimates will be validated for compliance with the DE Work Package Codes, the Contractor’s

Project DEXP, and all other TfNSW cost estimating requirements. These include DMS-ST-173

Cost Estimating for Infrastructure and Place Projects and T MU AM 01001 ST Life Cycle

Costing.

All 5D Model deliverables will be validated upon submission for compliance with the cost

classification, BIM classification and other Contract requirements.

6.8.5. Cost deliverable submissions

Cost estimate and 5D model deliverables are to be uploaded to the TfNSW ECM tool in

accordance with the ECM tool requirements specified in Section 3.3. Progress Claim and

Variation related submissions must be submitted in accordance with the requirements in the

Contract.







6.9. Asset data deliverables

Asset data deliverables are focused around the structured asset data that is created or captured during a project. This information assists with design development and verification and includes data and information specified by the Asset Information Requirements (AIR), including the O&M asset register (Handover Asset Register). Asset register data may be captured during the project phase within the BIM Model(s) or in the Asset Register template itself (refer to Figure 14).

Handover Asset Register+Asset Information

Asset list and otherasset information

BIM model

Current scope of DE

Is it an MMI?

Yes

Figure 14: Asset Data Development

Asset information, additional to the asset register (asset data), including manuals, certificates, warranties and procedures etc, is specified in the Contract and managed as for other project information, utilising the MIDP. Requirements specific to asset information handover are to be documented in the handover plan, as required by T MU AM 01014 ST Asset Information Handover Requirements and must consider the O&M’s information requirements (AIR), for example as specified in:

Sydney Trains Asset Information Delivery Plan (heavy rail assets)

ILC-GEN-TP0-901 Asset Acceptance Technical Procedure (road and maritime assets)

Bridge Inspection Procedure Manual (road-bridge assets).

To enable the asset information to be linked requires the use of a unique Project Asset ID that is common in the Asset Register, the BIM Model, and other data sets.

6.9.1. Asset register requirements

Asset data, documented in accordance with DMS-FT-537 Asset Register Template, is to be provided to TfNSW as part of a staged process, aligned with the Integrated Design Reviews. The minimum requirements for the submission of asset information in the form of an asset register are provided in Table 50.

The Level of Information (LoI) to be provided in the Asset Register submission at Integrated Design Reviews is specified in Table 51. The Asset List (AR PDS) attributes must be generated from the BIM Model with additional assets and/or attributes, as specified by TfNSW or the







Asset Custodian (eg the asset maintainer), appended and populated to generate the Handover Asset Register (refer to Figure 15).

Key TfNSW Project Team ContractorMaintainer

(eg Sydney Trains)

Project Data

Building Blocks

(PDBB)

BIM Schema

(includes Asset

Register PDS)

Develop the

BIM model(s)

Export the

developed Asset

List as per

DMS-FT-537

Maintainer confirms MMI

and additional attributes

required for the assets

Asset Register

updated with

additional attributes

(appended to Asset

List)

Asset attributes

populated at

optimum time in

the project

Handover to

Maintainer

Figure 15: Handover Asset Register creation (simplified process)

During the Plan-Acquire phases, an Asset Register must be submitted at Integrated Design Reviews as specified in Table 50 and Table 51. The Level of Information (LoI) required in the Asset Register becomes more detailed and defined as the design develops. The submitted Asset Register is utilised by TfNSW during design development for validation, verification and traceability. It also contributes to communicating design intent.

At the point of handover of the physical assets to the maintenance and/or operations phase, an extract from the Asset Register is taken to form the Handover Asset Register. This Handover Asset Register must represent those assets as-built and include a record for all assets to the MMI and as required by T MU AM 02001 ST Asset Information and Register Requirements, Section 7.1 Creation of assets in the asset register and as required by T MU AM 02006 TI Asset Register and Data Dictionary (Note: T MU AM 02006 TI Asset Register and Data Dictionary details the asset register data to be provided in lieu of the O&M providing their own TfNSW compliant asset register template, e.g. RAMS, BIS, Equip etc).







Table 50: Asset register submissions


Register Name

Description Minimum Requirement

3 CDD N/A - -

4 SBR System Breakdown Structure

Location list and asset list populated to reflect the System Requirements Specification (SRS) (refer to section 6.1).

Register completed as per DMS-FT-537 Asset Register Template.

Additional asset data as per contract requirements.

PDR Preliminary Design Asset Register

Complexes, entities, spaces/locations, elements and systems identified in the Asset List.

Information requirements for specified asset types to be included in the Asset Handover Plan, with consultation from the nominated O&M party.



DDR Detailed Design Asset Register

Complexes, entities, spaces, elements, systems and products identified in the Asset List.

The assets included in the Asset Register reflect the objects in the Federated Model, including parent EF and Ss relationships.



FDR AFC Asset Register





5 FSR N/A - -

ABR As-built Asset Register





Handover Asset Register

The minimal assets to be included in the register are to be determined as per T MU AM 02001 ST Asset Information and Register Requirements.

Assets identified as being MMI must have the additional information, as required by T MU AM 02006 TI Asset Register and Data Dictionary, appended to the Asset List or as per the O&M requirements.









Refer to Table 51 for the ABR stage asset register requirements, at the time of publication of this Standard. Refer to the latest version of DMS-FT-537 Asset Register Template for current requirements.

Table 51: Information required for inclusion in the ABR Asset Register

Ref. Field Name Attribute Name ABR inclusion

1. Asset List (AR PDS – Asset)

1.1 TfNSW Asset ID TfNSW_AssetID Optional

1.2 TfNSW Parent Asset ID TfNSW_ParentAssetID Conditional

1.3 Asset Location Code TfNSW_AssetLocationCode Mandatory

1.4 Asset Location Description TfNSW_AssetLocationDesc Mandatory

1.5 Asset Location Description Hierarchy TfNSW_AssetLocationDescHrchy Optional

1.6 Uniclass 2015 Asset Location Code TfNSW_UniclassAssetLocationCode Mandatory

1.7 Uniclass 2015 Asset Location Title TfNSW_UniclassAssetLocationTitle Mandatory

1.8 Parent Asset Location Code TfNSW_ParentAssetLocationCode Conditional

1.9 Project Asset ID TfNSW_ProjectAssetID Mandatory

1.10 Parent Project Asset ID TfNSW_ParentProjectAssetID Conditional

1.11 Asset Data Standard TfNSW_AssetDataStandard Mandatory

1.12 Asset Type Code TfNSW_AssetTypeCode Mandatory

1.13 Asset Instance TfNSW_AssetInstance Mandatory

1.14 Asset Code TfNSW_AssetCode Mandatory

1.15 Parent Asset Code TfNSW_ParentAssetCode Conditional

1.16 Asset Description TfNSW_AssetDescription Mandatory

1.17 Uniclass 2015 Asset Code TfNSW_UniclassAssetCode Mandatory

1.18 Uniclass 2015 Asset Title TfNSW_UniclassAssetTitle Mandatory

1.19 Top Level System Uniclass 2015 Code Uniclass_SsCode Optional

1.20 Top Level System Uniclass 2015 Title Uniclass_SsTitle Optional

1.21 Asset Label TfNSW_AssetLabel Mandatory

1.22 Asset Label Description Hierarchy TfNSW_AssetLabelDescHrchy Optional

1.23 Asset Type Configuration Code TfNSW_AssetTypeConfigCode Optional

1.24 Asset Type Configuration Description TfNSW_AssetTypeConfigDesc Optional

1.25 Discipline Code TfNSW_DisciplineCode Mandatory

1.26 Discipline Description TfNSW_DisciplineDesc Mandatory

1.27 Sub-discipline Code TfNSW_SubDisciplineCode Conditional

1.28 Sub-discipline Description TfNSW_SubDisciplineDesc Conditional

1.29 Asset Status Description TfNSW_AssetStatusDesc Mandatory

1.30 Asset Owner Organisation Name TfNSW_AssetOwnerOrgName Mandatory

1.31 Asset Maintainer Organisation Name TfNSW_AssetMaintainerOrgName Optional

1.32 Asset Operator Organisation Name TfNSW_AssetOperatorOrgName Optional

1.33 Work Package Name (Design) TfNSW_WPDesignName Mandatory

1.34 Work Package Code (Design) TfNSW_WPDesignCode Mandatory

1.35 Work Package Name (Supply) TfNSW_WPSupplyName Mandatory

1.36 Work Package Code (Supply) TfNSW_WPSupplyCode Mandatory

1.37 Work Package Name (Construction) TfNSW_WPConstructionName Optional

1.38 Work Package Code (Construction) TfNSW_WPConstructionCode Optional

1.39 Work Package Name (Commissioning) TfNSW_WPCommissioningName Optional

1.40 Work Package Code (Commissioning) TfNSW_WPCommissioningCode Optional

1.41 Project Contract Code (Design) TfNSW_ContractCodeDesign Mandatory

1.42 Contracted Organisation Name (Design) TfNSW_ContractOrgNameDesign Mandatory

1.43 Contract Name (Design) TfNSW_ContractNameDesign Mandatory

1.44 Project Contract Code (Supply) TfNSW_ContractCodeSupply Mandatory

1.45 Contracted Organisation Name (Supply) TfNSW_ContractOrgNameSupply Mandatory

1.46 Contract Name (Supply) TfNSW_ContractNameSupply Mandatory

1.47 Project Contract Code (Construction) TfNSW_ContractCodeConstruction Optional

1.48 Contracted Organisation Name (Construction)

TfNSW_ContractOrgNameConstruction Optional

1.49 Contract Name (Construction) TfNSW_ContractNameConstruction Optional

1.50 Project Contract Code (Commissioning) TfNSW_ContractCodeCommissioning Optional







Ref. Field Name Attribute Name ABR inclusion

1.51 Contracted Organisation Name (Commissioning)

TfNSW_ContractOrgNameCommissioning

Optional

1.52 Contract Name (Commissioning) TfNSW_ContractNameCommissioning Optional

1.53 Start km TfNSW_StartKm Mandatory

1.54 End km TfNSW_EndKm Conditional

1.55 GPS Coordinates TfNSW_GPSCoordinates Conditional

1.56 Maintenance Managed Item Flag TfNSW_MMIFlag Mandatory

1.57 Modelled Asset Flag TfNSW_ModelledAssetFlag Conditional

1.58 Source Model TfNSW_SourceModel Conditional

1.59 GUID GUID Conditional

1.60… For MMI, other attributes required by project contract requirements, for example:

T MU AM 02006 TI Asset Register and Data Dictionary

Sydney Trains Master Data Management (MDM) Templates

ILC GEN TP0 901 Asset Acceptance Technical Procedure

Bridge Inspection Procedure Manual

Conditional

2. Location List (AR PDS – Asset Location)

2.1 TfNSW Asset Location ID TfNSW_AssetLocationID Conditional

2.2 TfNSW Parent Asset Location ID TfNSW_ParentAssetLocationID Conditional

2.3 Project Asset Location ID TfNSW_ProjectAssetLocationID Mandatory

2.4 Parent Project Asset Location ID TfNSW_ParentProjectAssetLocationID Conditional

2.5 Asset Location Code TfNSW_AssetLocationCode Mandatory

2.6 Parent Asset Location Code TfNSW_ParentAssetLocationCode Conditional

2.7 Location Code Part TfNSW_LocationCodePart Mandatory

2.8 Asset Location Description TfNSW_AssetLocationDesc Mandatory

2.9 Work Type (Location) TfNSW_LocationWorkType Optional

2.10 Asset Location Description Hierarchy TfNSW_AssetLocationDescHrchy Optional

2.11 Uniclass 2015 Asset Location Code TfNSW_UniclassAssetLocationCode Mandatory

2.12 Uniclass 2015 Asset Location Title TfNSW_UniclassAssetLocationTitle Mandatory

2.13 Corridor TfNSW_Corridor Mandatory

2.14 Australian State TfNSW_AusState Mandatory

2.15 Suburb TfNSW_Suburb Mandatory

2.16 ASA Location TfNSW_ASALocation Mandatory

2.17 GPS Coordinates TfNSW_GPSCoordinates Conditional

2.18 Start km TfNSW_StartKm Mandotory

2.19 End km TfNSW_EndKm Conditional

Key requirements for the Asset Register submissions are:

• All objects in the submitted Federated Model must be represented in the Asset List (AR PDS – Asset) of all Asset Register submissions with the exception of the Asset Handover Register.

• All products (Pr) must be associated with a parent system (Ss). All systems (Ss) must be associated with a parent element or function (EF).

• At Asset Handover, the LoI included must be to the level of the MMI as per Section 7.1 in T MU AM 02001 ST Asset Information and Register Requirements.

• All MMIs must be identified by Final Design Review, in consultation with the Asset Custodian and O&M parties.

• Linear assets require both a Start Km and End Km. Non-linear assets (point assets) only require a Start Km.







• The Asset Type Code field must utilise the codes in DMS-FT-141 Master Classification Library, unless agreed with TfNSW and documented in the Project DEXP.

• All line-items in the Asset List must be associated with an Asset Location Code from the Location List (AR PDS – Location). An Asset Location Code can be associated with multiple Project Asset IDs.

• The Asset Location Code and Asset Location Description fields must utilise the codes in T MU AM 01007 TI Asset Reference Codes Register, unless agreed with TfNSW and documented in the Project DEXP.

• Asset Locations must be classified with Uniclass 2015 to the LoI specified in Table 52.


The asset data required to operate and maintain the assets is to be delivered as an Asset Register (based on DMS-FT-537), with classification provided in accordance with Uniclass 2015 to the levels specified in Table 52.




and

En_xx

and / or

SL_xx

4 Systems Breakdown Review Co_xx_xx En_xx SL_xx



Final Design Review


As Built Review




and

Ss_xx

and

As required




Final Design Review


As Built Review

Compliance with the data classification and coding requirements (NB classification and coding is discrete from referencing as required in Section 6.9.1) within T MU AM 02002 TI Asset Classification System is not required during the Plan/Acquire phase of IP projects.







Upon Contractor submission of the Asset Registers to TfNSW, TfNSW will assign the SER asset and location classification codes. This is done to reduce complexity and enable the use of Uniclass 2015 during Plan/Acquire phases for the Contractor, eliminating the need for duplicated effort in coding.

It must be noted that other asset owner standards, such as local councils are currently outside of the scope of this document. Refer to the Contract for these and other asset owner data requirements.


For brownfield sites, where the existing asset register(s) is provided by TfNSW to the Contractor project team at project commencement, the existing data and information are to be reviewed for relevancy to the project. Where existing data is to be re-used as part of a new deliverable, including the assets listed in the Asset Register, this data is to be classified in accordance with this DES, if not already compliant.

6.9.4. Validation and asset handover

At the completion of the Acquire phase, the Contractor must validate the Handover Asset Register and ensure compliance with the classification requirements and PDS.

The Asset Register data must consider the following:

• Validate all project data to ensure it is accurate and consistent with DE requirements

• Submit via the TfNSW ECM a complete copy of all PIM information

• Identify any additional project data that is required to be handed over for the O&M phase

• Submit via the TfNSW ECM a complete set of handover data as agreed with the O&M party, including the Handover Asset Register (based on DMS-FT-537) provided in .xls format.

Other documents and files must be validated in accordance with Section 3.3.







7. Project team responsibilities

All personnel in organisations delivering and managing assets for TfNSW play an important role in the production of reliable, consistent information. All project personnel must adopt the behaviours listed in Table 54 to help develop an appropriate working culture to facilitate successful DE.

Table 54: Digital Engineering team behaviours

Ref Project Behaviour Description

1 Share, collaborate, deliver

All personnel have a responsibility to share information, and where required, coordinate and collaborate to deliver TfNSW’s required Digital Engineering outcomes

2 Use common language

Use a common language so people can effectively exchange information

3 Auditable assurance pathway

Resolve issues collaboratively, manage risks and track decisions to provide a traceable and auditable pathway through design development up until asset disposal

4 Digital tools to support decision making

Implement effective tools and provide training so personnel are empowered to make decisions using the best available information

5 A platform to support innovation

Use Digital Engineering tools and processes to drive innovation in the way projects are delivered

Roles, responsibilities and levels of authority for the management, control and execution of DE activities and deliverables must be assigned to identified personnel within the project team, on both TfNSW and the Contractor sides, as agreed by the TfNSW DE Manager and the Contractor.

TfNSW will establish the following roles, with both general and specific DE responsibilities:

a. TfNSW Project Manager (PM), with DE management accountabilities

b. TfNSW DE Manager responsible for DE.

The Contractor will confirm the party(ies) and named person(s) who will be responsible for information modelling and DE management for the project in the Project DEXP, describing what activities will be performed and what authorities will be held by each individual. This includes overall responsibility and scope of appointments for both TfNSW and Contractor personnel, as appropriate to the project structure.

Allocations may change depending on project scope and complexity, and all engaged personnel must be able to demonstrate the required and appropriate experience, training and competencies.

The responsibilities listed in Table 55 may be performed by individuals or teams in larger projects, while functions may be combined for smaller projects or be combined with other project roles.







Table 55: Digital Engineering project responsibilities

Organisation Key Responsibilities

TfNSW Manages and coordinates project execution and DE to meet procurement strategy and cost containment

TfNSW Responsible for overall project DE strategy, procurement and implementation

Contractor Responsible for overall project DE strategy and implementation by the Contract Project Team

Contractor Responsible for the setup and delivery of the project from a DE perspective. This includes creation and management of the PIM and AIM in line with the project deliverables and this DES

Contractor Responsible for managing the overall production for the project’s federated BIM Model and associated data sets, including CAD

Contractor and/or TfNSW*

Responsible for managing the overall production for the project’s GIS data layer to be jointly agreed and Contractor and TfNSW are responsible for managing their own associated platforms

Contractor Responsible for initiation, agreement and implementation of information sub-plans, for control and governance of separate design packages (disciplines) and/or sub-contractor works

Contractor Ensures compliance for information management in accordance with the Contract, legislation and relevant SER and Industry Standards

Contractor Responsible for the day-to-day implementation of document control processes and system support

*to be agreed with TfNSW and documented in the Project DEXP or GIS Management Plan.

On projects that require integrated scheduling, cost and/or asset information, the Contractor must identify the roles and responsibilities of personnel that will be responsible for the production, control, assurance and federation of this information.







8. Assurance requirements

The Contractor must comply with the general assurance requirements for the project.

8.1. Quality assurance and quality control

Contractors must ensure all information deliverables for a project are structured in alignment with the TfNSW Project Data Schemas (refer to Table 25).

At each Submission TfNSW will review the data submitted to verify that all asset and other project data is complete, up-to-date and accurate.

Without limiting the quality assurance and quality control measures required elsewhere in Contract documentation, TfNSW requires Contractors to establish, implement and maintain quality assurance and quality control processes, procedures and protocols for Digital Engineering. These processes and procedures must be documented in the Project DEXP.

8.2. Performance management/ continuous improvement

TfNSW requires Contractors to manage and monitor performance throughout the planning, design and construction phases of the project.

The Contractor is to facilitate a Digital Engineering KPIs definition workshop within 4 weeks of Contract award. The KPIs must be agreed with TfNSW to inform the project delivery, as well as the TfNSW Digital Engineering Framework (DE Framework), including, but not limited to the KPIS listed in Table 56.

Table 56: Digital Engineering project Key Performance Indicators

KPI Area Benefit KPI

Communication Improved Design Clarity

Minimise administration overhead associated with responding to RFIs, through improved design clarity using BIM

No. RFIs

No. Business Days to Respond to RFIs

Design Reduced Rework

Minimise rework during construction, by improving the quality of the design through clash detection and construction sequencing

No. Design Changes (during construction)

No. Resubmitted design packages

Design Review Improved Design Review

Issues with designs identified and resolved faster, using BIM to review design and ECM to optimise collaboration and communication

No. Business Days to review design submissions

No. Business Days to close-out comments

Cost Reduced Commercial Risk

Minimise unexpected cost of variations during construction, by improving quality of design

No. Variations

% Cost Variance – Actual vs Baseline Cost

Time Improved Construction Durations

Minimise construction times and public disruption, by optimising the schedule

% Activities completed on time

% Time Variance - Actual vs Baseline Duration







KPI Area Benefit KPI

Quality Improved data accuracy

Ensure handover information for O&M is appropriate, complete and accurate, by more effective assurance of project deliverables.

Number of asset data errors at Integrated Design Reviews

Safety Improve Safety

Improve site inductions and safety training, using 4D BIM to support virtual construction and work simulation

Number of site inductions using visualisation tools

Number of incidents on site (lost time injury frequency rate)

The Contractor will undertake a KPI review and lessons learned workshop regarding the execution of DE within the project as part of the regular project reporting as required by the Contract. As a minimum, a KPI review and lessons learned workshop must be held at the end of each design phase.

The Contractor is required to detail in the DEXP appropriate performance indicators and analysis to demonstrate level of DE performance.







Appendix A - Reference of standards and guidelines

To successfully implement DE, Contractors are required to correctly apply relevant standards and best practice guidelines from Safety, Environement and Regulation (SER) (previously ASA), Operating Agencies, utility providers and industry. Table 40 provides a list of applicable standards and guidelines that Contractors must consider when implementing DE for TfNSW projects.

Table 57: TfNSW Digital Engineering – applicable existing standards and guidance

Applicable standards and guidance documents

Publication title

Guid

ance

Engin

eerin

g

Info

rma

tio

n

ma

nagem

ent /

CD

E

Asset

Info

rma

tio

n

Level of

Def/

Dev

Costin

g

Infrastructure & Place

DMS-ST-202 TfNSW DE Standard, Part 1 – Concepts and principles

DMS-ST-207 TfNSW DE Standard, Part 2 – Requirements

G73 Detail Survey

G75 Geographic Information Systems (GIS)

DMS-ST-173 Cost Estimating for Infrastructure and Place Projects

TfNSW SER -

TfNSW Asset Management Framework

- TfNSW Configuration Management Framework

- Transport Requirements for Assured Configuration Change (TRACC) Standard (DRAFT)

T MU AM 01001 ST

Life Cycle Costing

T MU AM 01005 ST

Asset Handover Requirements

T MU AM 01006 ST

Asset Reference Codes

T MU AM 01006 F1

Asset Location Classification Code Form

T MU AM 01007 TI

Asset Reference Codes Register

T MU AM 01008 ST

Technical Maintenance Plans and Coding System

T MU AM 01012 ST

Engineering Document Requirements

T MU AM 01012 F1

Metadata Spreadsheet for Engineering Documents

T MU AM 02001 ST

Asset Information and Register Requirements

T MU AM 02002 TI

Asset Classification System








Publication title

Guid

ance

Engin

eerin

g

Info

rma

tio

n

ma

nagem

ent /

CD

E

Asset

Info

rma

tio

n

Level of

Def/

Dev

Costin

g

T MU AM 02004 ST

Management of Asset Information

T MU AM 02006 TI

Asset Register and Data Dictionary

T MU AM 06004 ST

Requirements Schema

T MU AM 06006 ST

Systems Engineering Standard

T MU AM 06006 GU

Systems Engineering Guideline

T MU MD 00006 ST

Engineering Drawings and CAD Requirements

T MU MD 00006 TI

Technical Information for CAD and Engineering Drawings

T MU MD 00006 F1

Metadata Spreadsheet for Engineering Drawings

T MU MD 00014 GU

Multi-Discipline Rail Infrastructure Design Management

Mode specific requirements -

Roads and Maritime Services Schedule of Classified Roads and Unclassified Regional Roads

ILC-GEN-TP0-901

Asset Acceptance Technical Procedure

- Bridge Inspection Procedure Manual

- Sydney Trains Asset Information Delivery Plan

International and Industry

ISO 19650-1

Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) – Information management using building information modelling

Part 1: Concepts and principles

ISO 19650-2

Organization and digitization of information about buildings and civil engineering works, including building information modelling -- Information management using building information modelling: Delivery phase of the assets

BS1192:2007

Collaborative production of architectural, engineering and construction information. Code of practice








Publication title

Guid

ance

Engin

eerin

g

Info

rma

tio

n

ma

nagem

ent /

CD

E

Asset

Info

rma

tio

n

Level of

Def/

Dev

Costin

g

PAS1192-

2:2013

Specification for information management for the capital/delivery phase of construction projects using building information modelling

PAS1192-3:2014

Specification for information management for the operational phase of assets using building information modelling (BIM)

BS1192-4:2014

Collaborative production of information. Fulfilling employer's information exchange requirements using COBie. Code of practice

PAS1192-5:2015

Specification for security-minded building information modelling, digital built environments and smart asset management

BS 8536-2:2016

Design and construction : Code of practice for asset management (Linear and geographical infrastructure)

BIM Forum LOD 2018

LOD Specification 2018

AS 5488:2019 Classification of Subsurface Utility Information (SUI)

ISO 12006-2:2015

Building construction – Organization of information about construction works – Part 2: Framework for classification

NBS - Uniclass 2015

Unified Classification System for the Construction Industry

Standards and guidance developed by other authorities such as local authorities and utilities providers should be considered on a case-by-case basis. TfNSW also encourages Contractors to apply industry best practices, while meeting TfNSW’s minimum requirements.

Guidance from other relevant authorities and sources should be used to inform the development of the Contractor’s project specific DE Execution Plan (DEXP).







Appendix B –Levels of Detail indicative diagrams






B1 Bridge Structure

LoD 200 300 350 400

Bridge beam example

Element modelling to include

Type of structural concrete system

Approximate geometry (eg depth, length and width) of structural elements

Specific sizes and locations of main concrete structural members modelled per defined structural grid with the correct orientation

All sloping surfaces included in model element except elements affected by manufacturer selection

Reinforcing post-tension profiles and strand locations

Reinforcement modelled in congested/ interface locations or as a representative sample for each unique structural element

Chamfer

Pour joints and sequences to help identify reinforcing lap splice locations, scheduling, etc.

Lifting devices

Embeds and anchor rods

Penetrations for items such as drainage

Any permanent forming or shoring components

All reinforcement including post-tension elements detailed and modelled

Finishes






B2 Drainage

LOD 100 200 300 350

Drainage network example


Diagrammatic or schematic string model of drainage elements with placeholders

3D solid based model of elements with approximate size, shape and location of drainage pipes, pits and other drainage features

3D solid based model as design specified size, shape, spacing, location and grade of drainage pipes, pits, headwalls and other drainage features

Actual location of pits/ headwalls modelled based on setout details (not the centre of pit)

Actual location of pipe connections to pits/ headwalls modelled (centre of pit wall)

Hydraulic Grade Line (HGL) included based on minimum ARI for piped systems.

3D solid based model as actual construction elements

Actual size, shape, spacing, location, connections and slope of individual pipe lengths modelled

Actual size, shape, spacing, location, connections of pit and headwalls

Actual features attached to pits/ headwalls including grates, lids, lintels, step irons, railings etc.

Actual pit and headwall penetration modelled

Actual drainage trench depth and width modelled.

Hydraulic Grade Line (HGL) included based on minimum ARI for piped systems.






B3 Road Alignment/ Pavement

LOD 100 200 300 350

Road alignment/ Pavement Example


Simple planar surface generated from design tin, either split into individual surfaces for pavement, verges, earthworks etc. or a single design surface

3D solid based model with individual elements split by type with approximate size, shape and location of lanes, shoulders, pavement, earthworks, verges, medians, footways kerbs, etc.

3D solid based model as design specified size, shape, spacing, location of lanes, shoulders, pavement, verges, medians, footways, kerbs pram ramps etc.

Individual pavement layers modelled from top of wearing surface to the bottom of SMZ

Pavement edge details shown as a nominal box out including subsoil drainage trench.

Cut and fill embankments modelled as planar surface including any benches, berms, table/ catch drains.

Earthworks foundations treatments modelled as nominal box out.


Actual size, shape, spacing, location, of lanes, shoulders, pavement, earthworks, verges, medians, footways kerbs, etc

Pavement edge details modelled actual construction elements including benching/ stepping individual pavement layers, daylighting pavement and subsoil drainage trench and pipe.

Kerbs as actual construction elements including based details and interfaces with pavement edge details and drainage pit inlets modelled.

Cut and fill embankments as 3D solid based model including benches, berms, table/ catch drains with any batter/ cutting treatments or linings modelled.

Earthworks foundations treatments modelled as specified including bridging layers, working platforms, drainage blanket, cut/ fill transition zones






B4 Road Furniture

LOD 100 200 300 350

Road furniture Example


Diagrammatic or schematic string model of road furniture elements, safety barriers, fences and line marking as string elements and signs, street lighting etc. as symbols

3D solid based model, individual elements represent approximate quantity, size, shape, location and orientation including signs & sign face, safety barriers, fences, line marking, street lighting and other road furniture elements.

Foundations for signs, barriers, fences and street lighting is approximate, with a strip footing applied for safety barriers and fence to allow for alternative post spacing during construction.

3D solid based model as design specified quantity, size, shape, location and orientation including signs, safety barriers, fences, line marking, street lighting and other road furniture elements.

Sign faces are sizes and positioned as designed to allow clearance and visibility checks.

Foundations for signs and street lighting is as designed/ specified allowing for ground conditions and location.

Strip footing provided for safety barriers and fences to allow for alternative post spacing during construction.


Actual quantity, size, shape, location and orientation including signs, safety barriers, fences, line marking, street lighting and other road furniture elements.

Safety barrier and fence posts modelled actual construction spacing.

Safety barrier terminals and crash cushions modelled as constructed elements.






B5 Survey

LOD 100 200 300 350

Site Survey

Example


A simple topographic surface shown as a plane

Surface generated from 3D scanning information

A generic surface shown as a plane interpolation between the different elements including existing road pavement, kerbs, drainage features, slopes, retaining walls, buildings and other existing features

Surface generated from detailed design survey and supplemented by 3D scanning information

3D contours shown to define the surface within the model

Complete and accurate surface defined between the different elements including existing road pavement, kerbs, drainage features, slopes, retaining walls, buildings and other existing features

Surface generated from detailed survey and supplemented by 3D scanning information


Complete and accurate surface defined between the different elements

Existing features defined as separate elements within the survey model including existing road pavement, kerbs, signs, safety barriers, lighting, drainage features, slopes, retaining walls, bridges, buildings and other existing features

Surface generated from detailed survey and supplemented by 3D scanning information







B6 Utilities

LOD 100 200 300 350

Drainage network example


Diagrammatic or schematic string model of utility elements, pipes, conduits and cables as string elements and pits, valves, hydrants, posts etc. as symbols

Utility data generated from topographical survey, tracing surface features (Quality level C) and supplemented with DBYD records (Quality Level D).

3D solid based model of elements with approximate size, shape and location of pipes, conduits, cables, pits, jointing bays, thrust blocks, hydrants, scour valves, poles and other utility features

Pipes, conduits, cables etc. sizes based on utility survey or DBYD records.

Pits, jointing bays, thrust blocks, hydrants, scour valves etc. size based on typical details from utility owner.

Conduits banks can be modelled as a single box rather than individual conduits.

Subsurface utility data generated from utility survey (Quality level B), topographical survey, tracing surface features (Quality level C) and supplemented with DBYD records (Quality Level D).

Surface utility data generated from topographical survey and typical pole

3D solid based model as surveyed size, shape, spacing, location and grade of pipes, conduits, cables, pits, jointing bays, thrust blocks, hydrants, scour valves, poles and other utility features

Pipes, conduits, cables etc. sizes based on utility survey

Pits, jointing bays, thrust blocks, hydrants, scour valves etc. size based on utility survey and pit reports.

Conduits banks can be modelled as a single box rather than individual conduits.

Subsurface utility data generated from utility survey, potholing and pits report (Quality level A & B) and topographical survey, tracing surface features (Quality level C).

Surface utility data generated from topographical survey including surveyed pole/ arm heights and catenary survey for wires.

3D solid based model as surveyed size, shape, spacing, location and grade of pipes, conduits, cables, pits, jointing bays, thrust blocks, hydrants, scour valves, poles and other utility features

Pipes, conduits, cables etc. sizes based on utility survey

Pits, jointing bays, thrust blocks, hydrants, scour valves etc. size based on utility survey and pit reports.

Actual size, shape, spacing, location, and connections of pipes/ conduits modelled

Individual conduits modelled.

Actual features attached to pits including grates, lids, step irons etc. modelled

Subsurface utility data generated from utility survey, potholing and pits report (Quality level A & B) and topographical survey, tracing surface features (Quality level C).






LOD 100 200 300 350

heights, tracing cables between poles (Quality level C).

Surface utility data generated from topographical survey including surveyed pole/ arm heights and catenary survey for wires.